提议：音源插件支持注册「可搜索的独立平台」（如塞壬唱片），对齐 lx-music / MusicFree 的自定义源能力

[lingdiansr]

提议：音源插件支持注册「可搜索的独立平台」（如塞壬唱片），对齐 lx-music / MusicFree 的自定义源能力

背景

插件系统目前的音源能力有两个：

1. 播放地址兜底：musicUrl 只对 wy / tx / kg 三个 key 调用——播放器已认识的内置平台曲目拿不到官方地址时，由插件换地址；
2. 元数据兜底：musicSearch / musicLyric / musicPic / musicComment 对任意 key 生效，宿主内部匹配后补歌词 / 封面 / 评论。

这套设计的问题：平台的集合被锁死在内置三平台，插件无法为播放器带来"新平台"。搜索界面只搜 netease / qqmusic / kugou，插件注册的其它 key 永远不会出现在搜索里，其 musicUrl 也永远不会被调用。

历史背景：上一代 SPlayer 中「引入更多音源」的诉求已多次出现（#1078、#1070），但老架构是内置网易云 + unblock 解锁、无插件机制，诉求均未承接。插件系统是 SPlayer-Next 相比上一代的核心增量，理应成为承载「自定义音源」的载体。

具体痛点：塞壬唱片（Monster Siren Records）

塞壬唱片是明日方舟官方音乐厂牌，具备完整公开的官方 API（monster-siren.hypergryph.com）：

• 全量曲库 896+ 首（/api/songs），官方音频直链（wav / mp3，/api/song/{cid} 的 sourceUrl）
• 官方 LRC 歌词（lyricUrl）与专辑封面，接口无鉴权、无加密

我为此写了一个 SPlayer-Next 插件（splayer-next-msr），实测确认：

• ✅ 元数据兜底全链路正常：musicSearch 匹配塞壬曲库、musicLyric 返回官方 LRC、musicPic 返回封面
• ❌ 但无法搜索、无法播放塞壬曲目：musicUrl 因无平台 key 永不被调用；搜索界面没有插件入口；sourceUrl（音频直链）进不了播放器

最终插件只能作为本地文件的歌词 / 封面兜底使用，塞壬的完整曲库与官方音频对 SPlayer-Next 用户不可见。同类平台（B 站音乐、同人音声站等只有公开接口、无内置 key 的源）都有同样的问题。

期望能力

希望插件能注册「可搜索的独立平台」，打通 搜索 → 播放 完整链路：

1. 搜索入口：搜索界面的音源列表从「内置三平台 + 已启用插件声明的搜索源」聚合；用户选插件平台搜索时，关键词透传给插件的 musicSearch（已有处理器，直接复用）；
2. 播放链路：插件 musicSearch 返回的候选（id / name / singer / album）可直接入列播放；播放时宿主按候选所属 key 调插件 musicUrl（或复用候选中的直链字段）取音频地址；
3. 元数据不变：歌词 / 封面兜底维持现状，插件平台曲目与内置平台同等享受。

实现上主要增量是：搜索路由（渲染层聚合插件源 + IPC 透传）+ 播放调度（把插件候选纳入可播放 track，source 记为插件 key）。插件 host、musicSearch 处理器、musicUrl 调度、source key 机制都可复用，不需要新沙箱能力。

与其他项目对比

项目	自定义源模型	搜索入口
lx-music-desktop	user_api 脚本提供 search + getMusicUrl	音源出现在搜索来源列表，可搜可播
MusicFree	插件注册 platform，搜索 / 详情 / 播放全由插件提供	插件平台直接在搜索页可选
SPlayer-Next	兼容 lx 脚本，但只覆盖地址解析（musicUrl）	无插件搜索入口

SPlayer-Next 兼容层已经证明宿主有能力执行插件搜索逻辑（musicSearch 在兜底流程中运行良好），缺口只是把这条通路接到 UI 搜索与播放调度上——这也是与 lx-music / MusicFree 插件模型的核心差距。

征询意见

• 这个需求是否值得做？塞壬唱片只是案例，能力本身对任何「有公开 API 的独立音乐源」通用；
• 插件声明方式：沿用 actions 加一个枚举（如 "musicSearch" 兼作搜索源声明）还是新增独立字段？
• 播放调度：插件候选的音频应走 musicUrl（统一、可带 expire）还是允许候选直接携带 url（简单、少一次往返）？
• 优先级与 UI：插件搜索源与内置平台并列展示，还是放到「更多」折叠菜单？