开头
如果你家里有一台NAS、一台小爱音箱，又恰好刷到过"10分钟部署xiaomusic，彻底告别音乐会员"这类教程，那你大概率是这一万多Star里的一个。
但最近打开xiaomusic的GitHub页面，你会发现仓库顶部多了一行刺眼的字：This repository has been archived. 项目停止维护，不再接受新功能开发和bug修复，已有issue与PR也不再处理。GitHub一个运行了近三年、被无数NAS玩家当成"客厅听歌标配"的开源项目，就这么按下了暂停键。
停更公告里给出的去处是社区接力项目Songloft。问题是：接得住吗？老用户要不要跟？这篇把账算清楚。
一、先说结论：已部署的别慌，但也别装没事发生
评论区问得最多的一句话是："部署完成的xiaomusic还能继续用吗？"答案是能。Docker容器还在跑，小爱还能点歌，今晚的歌照播。
但归档意味着三件事只会越来越糟：
第一，仓库里还挂着一百多个没处理的issue和PR，以后也不会有人看了。你遇到的小概率bug，就是永久bug。
第二，xiaomusic的原理是走小米账号接口控制音箱。小米这类接口历来"说变就变"，当年MusicFree、各种第三方播放器都领教过。接口一旦调整，归档项目没有人会跟进修复——你的小爱会突然"听不懂"点歌指令，而且没有时间表。
第三，新设备、新固件不会适配。评论区已经有用户反馈跨网段部署、新版固件识别异常之类的问题，这些在归档状态下都成了无解题。
所以真实的选择题不是"要不要迁移"，而是"现在迁，还是等它哪天突然不工作再迁"。
二、Songloft是什么来头？先澄清一个以讹传讹的说法
小红书上那篇停更笔记的标题是"作者带来了全新项目"。小红书而xiaomusic README里写的是"社区接力项目"。GitHub两个说法打架，到底谁对？
查了一下，答案是：都对，但都不完整。Songloft的开发提交记录里，绝大多数commit仍然来自原作者hanxi本人，项目文档站就挂在songloft.hanxi.cc——说"完全换了个团队"不准确。但项目确实从个人仓库挪到了songloft-org组织下，定位也刻意往"社区项目"转。
还有一层很多人不知道的：Songloft原名MiMusic，2026年5月底的v2.0版本才改名，内核和功能不变，纯品牌升级。Songloft文档站所以你在某些老帖子里看到的MiMusic部署教程，说的就是它。
看数据的话，这个项目目前1400多Star，从5月底改名到8月中旬，不到三个月发了44个版本，最新版v2.11.5就是这两天刚推的，仓库最近一次提交就在昨天。而且它不是一个人在战斗：songloft-org名下已经挂了20多个仓库，从小爱音箱的MIoT插件、Subsonic/WebDAV兼容插件，到歌词刮削、卡拉OK逐字歌词、播放统计、公网穿透插件，甚至还有人专门做了路由器和光猫的部署方案。对一个小众自托管项目来说，这个更新密度和生态铺开速度相当能打——至少说明现在接手的团队不是来玩票的。
三、定位变了：从"免费听歌神器"到"音乐库服务器"
这是迁移前必须想清楚的一件事，也是老用户最容易失望的地方。
xiaomusic当年的口号是"无限听歌，解放小爱音箱"，内置yt-dlp下载，说一句歌名就能现下现播，本质是一个"在线点歌机"。而Songloft的官方定位写得明明白白：面向个人用户的自托管音乐服务器，仅管理你合法拥有的音乐。GitHub具体到功能上，变化有三点：
内置下载没了。当年lxmusic那类聚合音源插件在改名时被以"legal cleanup"的名义移除。现在官方插件商店里有下载器插件和yt-dlp导入插件，但官方的口径是"用户须自行承担版权合规责任"。GitHub换句话说，它不再替你把"免费听所有歌"当作卖点。
本地库管理变成了主菜。扫描本地目录自动提取封面、歌词、元数据，支持MP3/FLAC/WAV/APE/OGG/M4A等主流格式，连MKV这类视频容器里的音轨都能识别——给娃囤的英语启蒙音频、有声书这类场景反而被照顾到了。评论区有家长说"给娃定时放英语全靠xiaomusic"，这类需求在Songloft里是加分项。
多端播放是新增的大头。Flutter客户端覆盖安卓、iOS、macOS、Windows、Linux、Web六端，还有Kodi插件和电视客户端，支持Subsonic协议和WebDAV插件，也能作为Home Assistant加载项一键安装。Songloft文档站也就是说它不只是小爱音箱的桥，而是想把整个家的播放端都接进来。
一句话总结：你失去的是"白嫖点歌机"，得到的是"正经音乐库中枢"。如果你NAS里本来就躺着几百GB自己攒的无损，这个交换是划算的；如果你从来都是现搜现下没存过歌，那Songloft的设计哲学跟你不是一路人。
四、小爱语音点歌还在吗？在，但姿势变了
这是迁移党最关心的问题，官方答案和知乎实测都确认：装"智能音箱"（MIoT）插件后，小爱语音点歌依然成立。知乎流程大致是：
Songloft部署好后，进"设置-扩展-插件商店"安装"智能音箱"插件（网络不通可以在设置里切GitHub加速地址）；
在"外观设置"里把智能音箱模块手动开启；
进入插件页配置内网地址，打开"对话监听"和"语音指令"，指令词可以自己定义；
账号管理里扫码登录米家，设备列表里勾选你的小爱；
选择歌单和设备，就能语音点播NAS里的歌了。
而且细节上确实下了功夫。翻更新日志能看到一堆针对小爱的专属修复：小爱固件会把URL里的&符号吞成空格，Songloft的认证中间件专门做了兼容。Songloft文档站音箱只支持从头拉流，服务端就用ffmpeg做input seek切片；音箱解不了AAC和HLS，就提供实时转MP3的radio_transcode参数。这种级别的适配，说明开发者是真的拿小爱当主力场景在调。
翻MIoT插件自己的仓库还能看到两个加分项：一是设备分组，把客厅、卧室几台小爱拉进一个组，任何一台点播，全组同步播放，多房间背景音乐就这么解决了；二是定时任务带法定节假日感知，"工作日早上播新闻、节假日睡懒觉"这种需求能直接设成真·工作日模式，调休补班的周末都会强制触发。GitHub评论区那位"给娃定时放英语"的家长，这功能就是为你准备的。
但要提醒两个预期差：一是语音点歌是通过"对话监听"实现的——插件在后台听小爱的对话再触发指令，跟小米原生语音链路不是一个机制，响应慢半拍属于结构性的，别指望跟喊QQ音乐一样跟手；指令词也需要按自己的习惯重新配一遍。二是米家接口本身是第三方接入，小米哪天调整策略，这类玩法都会受影响——这也是xiaomusic当年的隐患之一，迁移并不能一劳永逸地消除它。
五、迁移避坑清单
真决定迁的，下面这几条能省你不少时间：
音乐文件直接复用。 xiaomusic下载的目录（按歌手分文件夹那套）可以直接挂给Songloft扫描。注意Songloft只认一个音乐根目录，多个目录要么挂载到根目录子文件夹，要么用软链接。另外默认不会自动扫描，要在"设置-音乐库管理"里手动触发，很多人部署完看到空白页就是卡在这一步。知乎
默认密码必须改。 默认账号admin/admin，官方文档把它标成"仅适用于本地测试"。GitHub只要你的NAS有公网访问或者多设备接入，部署时就用ADMIN_PASSWORD环境变量设强密码，别等库被人访问了才想起来。
时区要设TZ=Asia/Shanghai。 涉及定时扫描、定时播放这类功能，不设时区会差8小时。Songloft文档站
iOS客户端要自己签名。 安卓有现成APK，iOS端目前需要自签，嫌麻烦的可以先用Web版。
老容器别急着删。 建议Songloft和xiaomusic并行跑一两周，确认语音点歌、歌单、定时任务这些场景都验证过了，再停掉旧容器。音乐文件本身不动，随时可以回滚。
六、谁不用跟着迁
最后说清楚三种可以按兵不动的情况：
第一，你的xiaomusic用得很稳，需求就是"能听就行"。归档版短期不会死，等它真的不工作了再迁，损失不大——风险只是到时候你要临时抱佛脚。
第二，你更看重曲库管理和Subsonic生态，Navidrome用得挺好。Songloft评论区里也有人问"相比Navidrome有什么优势"，目前的答案是：两者定位有重叠但生态不同，Navidrome的第三方客户端生态更成熟，而且社区还在等Songloft放出Navidrome兼容插件，现在切换没有硬理由。
第三，你主要依赖"搜歌名直接播"的在线点歌，本地根本没有曲库。Songloft的合规化路线决定了它不会把这条路当主打，强行迁过去只会觉得处处受限。
值得继续盯的信号：Songloft的版本节奏（如果哪天慢下来了，说明接力热情退潮）；MIoT插件的issue区语音延迟问题是否收敛；以及Navidrome兼容插件什么时候上。这三个信号任何一个有变，结论可能要重写。
折腾NAS的乐趣就在于，工具会老，但你的音乐库是自己的。xiaomusic陪跑的这三年，攒下来的每一首歌都不会白费——换个更结实的架子继续听就好。
