这台小米音箱在我家当了很长一段时间的“试听机”。跟它说放某首歌，能搜到的只能听个十几秒，想听完整版就要开会员；搜不到的直接装死。后来我把NAS里的音乐库整理了一遍，又折腾了DLNA、Home Assistant这些东西，才算是彻底改变了局面——小爱音箱现在能直接播放NAS里的无损音乐，也能播网络电台、播客这类流媒体，组成了标题里说的“多音源方案”。
这篇就把整套折腾过程完整写下来：先讲清楚小爱的“试听”限制到底卡在哪，再给三条从NAS往小爱送音乐的路线，然后是NAS端媒体服务搭建、手机推流的完整实操，最后是我实际用了半年多踩过的坑和稳定化经验。适合手上有NAS、家里有小爱音箱、又不想被在线曲库和会员试听绑架的朋友参考。
1. 先搞清楚“只能试听”卡在哪：小爱的音源边界与DLNA突破口
1.1 小爱为什么放着本地歌不播
小爱的音乐链路是这样的：你说“小爱同学，放周杰伦”，语音请求先到小米云端，小米再去内容服务商（QQ音乐、酷狗、网易云这些）查曲库，最后返回给音箱播放。整个过程里，NAS上的文件压根不在它的内容目录里。
“试听”限制其实不是音箱硬件造成的，而是内容方的商业策略：免费用户给试听片段，完整版和高品质音频要会员。而小爱作为一台“云音箱”，本地文件访问能力和局域网发现能力被刻意弱化了——官方App里根本没有让你输入音频URL的入口。
但硬件上它并不差：有Wi-Fi、有音频解码能力、有扬声器。只要你能给它一个“可访问的音频URL”，它其实是可以播的。问题只在于怎么绕过官方App的封闭入口。
1.2 现实里有哪些路可以绕
我实测过后，能跑通的主要有三条路：
| 路线 | 依赖条件 | 折腾成本 | 体验 |
|---|---|---|---|
| DLNA推送 | 小爱音箱支持DLNA接收 | 中 | 最好，不依赖手机常驻 |
| 蓝牙桥接 | 小爱支持蓝牙 | 低 | 一般，手机得一直连着 |
| Home Assistant中转 | 会配Docker和YAML | 高 | 最灵活，场景自动化最强 |
DLNA是首选。只要你的小爱固件里带DLNA/UPnP渲染器功能，NAS上架一个媒体服务器，手机装一个控制端App，就能把NAS上的歌“推”给音箱播放。整个过程走局域网，不经过小米云，也就没有试听限制。
1.3 要不要刷机？先别急
很多人在问“小米AI音箱刷机有什么作用”，我的观点很直接：绝大多数需求不需要刷机。官方固件配合DLNA和Home Assistant，已经把“播NAS本地音乐”“播放网络音源”“定时自动播放”这些核心需求全覆盖了。刷机后面临固件不再更新、安全补丁缺失、变砖风险，而音箱又是个常年联网设备，风险远大于收益。如果你手里那台确实不支持DLNA，先用蓝牙方案顶着，或者花几十块收一台支持DLNA的二手小音箱，都比刷机稳。
2. 多音源方案总览：三条路把NAS音乐送到音箱手里
2.1 路线A：DLNA媒体服务器，NAS当曲库、音箱当播放器
这就是标题里说的“本地NAS音源”方案。DLNA体系里通常有三个角色：
- 数字媒体服务器（DMS）：跑在NAS上，比如minidlna、Emby、Jellyfin、群晖Media Server，把音乐文件夹发布成可浏览的媒体库；
- 数字媒体渲染器（DMR）：小爱音箱自己，负责接收指令并拉取音频流播放；
- 数字媒体控制器（DMP）：手机上的BubbleUPnP这类App，负责浏览媒体库、选择渲染器、推播放指令。
打个比方：服务器是CD架，音箱是CD机，手机App是遥控器。只要CD架在局域网里能被发现，CD机又能播放网络URL，CD架上的歌就能在CD机里响起来。
好处是彻底绕开在线曲库，NAS里几千个文件变成可搜索的列表；坏处是需要设备支持DLNA，且音箱的解码能力决定能放什么格式。
2.2 路线B：蓝牙桥接，兼容性最广的退路
如果你的小爱音箱不支持DLNA，蓝牙桥接是最简单的兜底方案。操作思路是：手机或平板蓝牙连上小爱，然后在手机端用VLC、nPlayer、Emby客户端这类App播放NAS上的文件，声音经蓝牙送给音箱。
这条路的优势是不挑型号，所有带蓝牙的小爱都能用；缺点是手机得一直连着音箱，距离受限，来电话、通知音都会打断播放，体验比较粗粝。适合偶尔听一听，不适合做稳定的日常方案。
2.3 路线C：Home Assistant做大脑，把音箱变成自动化终端
Home Assistant（HA）跑在NAS的Docker里，通过小米集成把小爱音箱变成一个可编程的“播放终端”。你可以写自动化：工作日早上7点半让小爱播NAS里的晨间歌单；按下无线开关切换音源；甚至门外有人按门铃时，暂停音乐并让音箱念一段提示。
这条路本质是把“人用手机推流”升级成“系统自动推流”，是所有路线里天花板最高的。后面第五章会有具体实操。
2.4 选型建议
我的建议是：喜欢手动挑歌、追求稳定，直接走A；设备老旧不支持DLNA，先走B过渡；有智能家居自动化需求，在A跑通之后叠加C。A和C不是互斥关系，HA也可以复用DLNA那套基础设施。别一上来就三条路全上，会把自己折腾疯。
3. 开干之前先收拾音乐库：目录、标签、格式的取舍
3.1 音乐目录怎么建才不乱
不管你最后用minidlna还是Jellyfin，目录结构直接决定媒体库的排序和后续维护成本。我目前的布局是：
/music/ 艺术家/ 专辑名/ 01 曲目.flac 02 曲目.flacNAS里的共享文件夹名我建议用英文或拼音，避免某些SMB客户端出现编码问题；文件夹内部的“艺术家/专辑”这层可以用中文，媒体服务器一般都能正确处理。强烈建议批量清理那些“新建文件夹(1)”之类的名字，不然DLNA库建出来乱七八糟，选歌都费劲。
如果你手上曲库很乱，推荐用Advanced Renamer或FileBot做批量重命名，几分钟就能把几百个文件夹规范好。
3.2 标签和封面，决定媒体库好不好看
DLNA服务器不是靠文件名，而是靠音频文件内嵌的ID3/FLAC标签来生成媒体库。文件里没有标签，就会出现一堆“未知艺术家/未知专辑”，体验直接打骨折。
我常用三个工具：
- MusicBrainz Picard：自动识别歌曲信息并补全标签，适合英文歌和主流中文歌；
- Mp3tag：批量编辑标签、嵌入封面，速度最快；
- beets：命令行神器，适合喜欢自动化脚本的人。
封面建议直接嵌入到文件内部，而不是外挂一个cover.jpg——多数字媒体服务器对内嵌封面的支持更统一，外挂封面经常不显示。
3.3 格式兼容性：哪些能喂给小爱
小爱通过DLNA播放NAS文件时，很多媒体服务器（尤其是minidlna）不做转码，直接把原始文件URL丢给音箱，音箱解码不了就直接播放失败。所以格式兼容性得心里有数。
| 格式 | 小爱DLNA直接播放 | 个人建议 |
|---|---|---|
| MP3 | 基本都行 | 通用兜底格式 |
| AAC/M4A | 大多支持 | 苹果生态转出来的常见 |
| FLAC | 新款设备多数支持 | 建议主力格式，无损且兼容性持续变好 |
| WAV | 支持 | 体积太大，不适合做主力 |
| APE | 通常不行 | 别喂给音箱，转FLAC |
| DSD/ISO | 基本不行 | 放给解码器，别指望音箱 |
经验是：主力用FLAC和MP3双轨，APE这类老格式抽个时间批量转成FLAC，DSD就当不存在。音箱本身音质上限就摆在那，追求极致DSD没意义。
4. 核心实操：给NAS搭DLNA媒体服务，并把歌推给小爱
4.1 NAS自带DLNA服务的配置方法
群晖用户最省事：套件中心搜索“媒体服务器”（Synology Media Server），安装后在设置里添加音乐索引文件夹。群晖会默认开启DLNA，端口一般走8200。打开后，在手机BubbleUPnP的“媒体服务器”列表里就能看到群晖。
威联通、极空间、绿联这些系统也大同小异，找“DLNA”“媒体服务器”“媒体中心”这类入口开关。如果你用的是飞牛（fnOS）这类新系统，自带面板里如果没有DLNA选项，最简单是直接跳到4.2跑Docker版minidlna，一样稳定。
4.2 通用Linux老机器和Docker部署minidlna
不管NAS系统是什么，只要支持Docker，就能一套方案通吃。minidlna（也叫ReadyMedia）是个老牌轻量DLNA服务，资源占用极低，一台J1900、J4105这种老家伙跑起来毫无压力。
Debian/Ubuntu这里用的是系统包：
sudo apt update sudo apt install minidlna -y编辑配置/etc/minidlna.conf，核心几行：
media_dir=A,/srv/music friendly_name=MyMusicNAS db_dir=/var/cache/minidlna inotify=yes log_level=warnA前缀表示这个目录是音频目录，friendly_name记得改成你喜欢的名字，不然局域网里一堆“minidlna”同名设备，手机端根本分不清。启动服务：
sudo systemctl enable --now minidlna然后访问http://NAS的IP:8200/看到minidlna页面就说明服务起来了。记得在防火墙放行TCP 8200和UDP 1900——UDP 1900是SSDP发现协议用的，不放行手机可能发现不了音箱或服务器。
Docker方式更干净：
docker run -d --name minidlna --restart=unless-stopped \ -p 8200:8200 \ -v /srv/music:/media \ -e MINIDLNA_MEDIA_DIR=/media \ -e MINIDLNA_FRIENDLY_NAME=MyMusicNAS \ -e MINIDLNA_INOTIFY=yes \ vladgh/minidlna文件一多，首次建索引会花几分钟，耐心等手机端刷新。
4.3 手机推流到小爱的完整操作
安卓推荐BubbleUPnP，iOS可以用mconnectHD或8player这类支持UPnP/DLNA的App。
以BubbleUPnP为例，完整链路是：
- 手机和小爱连同一个Wi-Fi；
- 打开BubbleUPnP，下拉刷新，LAN区域里出现“媒体服务器”（NAS）和“渲染器”（小爱音箱）；
- 在媒体服务器里浏览NAS音乐库，选中单曲或整张专辑；
- 点播放，渲染器选择小爱音箱；
- 音箱开始出声。
整个过程中手机只是“遥控器”，选完歌之后手机就算锁屏也不影响NAS直接往音箱推流。如果小爱没有出现在“渲染器”列表里，重点排查三件事：
- 路由器有没有开“AP隔离”或访客网络（这个最容易踩，后面细说）；
- 小爱App里有没有蓝牙/DLNA相关的接收开关；
- 音箱固件是不是太老，尝试重启一次。
4.4 网络音源：电台、播客和自定义流
DLNA不仅能放NAS里的文件，也能放“网络URL”。在BubbleUPnP里可以直接添加或打开一个音频流地址，比如某个公开网络电台的mp3/m3u链接、某档播客的单集音频，选好渲染器直接推给小爱。
更进一步，你还可以在NAS上自己造一个“私有电台”。用ffmpeg循环播放某个歌单并输出成HTTP流：
ffmpeg -re -stream_loop -1 -i /srv/music/playlist.m3u8 \ -c:a libmp3lame -b:a 128k -f mp3 http://0.0.0.0:9000/live.mp3再把这个URL推给小爱，NAS就变成一个小型电台发射站。播放列表可以随时改，家里长辈不用学DLNA，一句话说“打开那个网址”就行。
5. 进阶玩法：自动化、情景模式与iPhone AirPlay
5.1 Home Assistant把小爱变成可编程播放器
NAS上跑一个HA容器就能开始玩。最简起法是：
docker run -d --name homeassistant --restart=unless-stopped \ -v /path/to/ha_config:/config \ --network=host \ ghcr.io/home-assistant/home-assistant:stable启动后用浏览器访问http://NAS的IP:8123做初始化。接入小米设备有两个路子：老牌做法是通过HACS装xiaomi_miot这类第三方集成，把米家账号绑上来；新版HA也逐步加入了对小米Home的支持，具体看版本。绑定成功之后，小爱音箱会以media_player.xxx的形式出现在HA实体列表里。
这时候，HA就能给音箱发送播放URL了。
5.2 定时播报与场景自动化
要让HA能稳定给小爱推送音乐，建议在NAS上再挂一个轻量静态文件服务，把音乐目录暴露成HTTP地址，比如http://NAS_IP:8000/music/...。Docker跑一个nginx就够：
docker run -d --name music-web --restart=unless-stopped \ -p 8000:80 \ -v /srv/music:/usr/share/nginx/html:ro \ nginx:alpine然后写一条自动化，工作日早上7点半播放晨间歌单：
alias: Morning Play NAS triggers: - trigger: time at: "07:30:00" conditions: - condition: time weekday: - mon - tue - wed - thu - fri actions: - action: media_player.play_media target: entity_id: media_player.xiaomi_living_room data: media_content_id: "http://192.168.1.100:8000/morning/01.flac" media_content_type: "music"原理不复杂：HA拿到一个音箱能访问的HTTP音频URL，调用播放服务，音箱就去NAS上拉流播放。相比去解析DLNA资源URL，静态文件URL简单得多，也不容易出现权限问题。
既然HA都接上了，场景就能随便玩：门铃触发时暂停音乐、睡觉前自动切到白噪音播放列表、NAS新入库专辑时自动推送到音箱试听。这些本质上都是“找到合适的URL，然后播放”。
5.3 给iPhone用户的AirPlay补丁
你的小爱如果支持DLNA，但你想从iPhone直接隔空播放，可以用AirConnect（也叫AirBridge）这个开源工具。它会把局域网里的DLNA渲染器“伪装”成AirPlay设备，iPhone的隔空播放列表里就会多出一个“小爱音箱”。
部署同样是Docker：
docker run -d --name airconnect --restart=unless-stopped \ --network=host \ mbooth/airconnect启动后打开它的管理面板，把小爱音箱启用为AirPlay目标。之后iPhone上无论是系统音频、Apple Music、还是VLC打开NAS文件，直接隔空播放到小爱。这个方案把“多音源”的最后一块补上了：安卓手机走DLNA控制端，iPhone走AirPlay，NAS走自动化和定时，全部汇到同一个小爱音箱上。
6. 半年实测踩坑实录：DLNA发现的鬼问题与稳定化技巧
6.1 DLNA设备“失踪”和“串台”
踩得最多的坑就是手机端发现不了小爱。我排查一圈后发现核心原因基本都是路由器开了AP隔离或访客网络，导致设备之间虽然在同一个Wi-Fi下，但互相不可见。解决办法是给小爱和NAS都固定IP，放进同一个网段，关掉AP隔离，必要时给NAS设DHCP静态分配。
另一个问题是局域网里DLNA设备一多，手机App偶尔把歌推到邻居家的电视或另一台音箱上。改名是第一个动作——minidlna里改friendly_name，小米设备在米家App里也能改名。更稳妥的做法是在路由器上按MAC固定IP，让设备标识稳定。
6.2 转码与卡顿，老NAS别硬扛
群晖Media Server这类自带方案如果开了转码，老NAS（比如J3455这种）在播放FLAC转MP3的时候CPU直接拉满，音箱端反而更卡。我最终把转码选项关了，让小爱直接解码原始文件。实测下来，新款小爱直接解码FLAC没问题，老设备遇到FLAC播不了，转成MP3比让NAS转码稳定得多。
卡顿还有一个隐蔽原因：音箱在拉取大体积FLAC时，Wi-Fi信号弱或路由器处理不过来回导致缓冲。如果条件允许，把NAS用网线接路由器，小爱靠近路由摆放，卡顿直接消失。
6.3 文件更新后列表不刷新
换了音乐文件，DLNA列表却还停留在老版本，这是媒体库索引缓存的问题。minidlna开启inotify=yes之后，大部分文件变动能自动感知；但如果你是一次性批量导入几百G文件，最好还是手动重启服务：
sudo systemctl restart minidlna群晖这类系统也有“重建索引”按钮，在媒体服务器套件里触发一次，稍等片刻列表就正常了。另外，频繁增删文件的操作尽量放在晚上进行，因为索引重建期间CPU会有一波明显占用。
6.4 一点实用心得
最后分享几个让我省心的小习惯。第一，小爱音箱在路由器里设固定IP，重要设备别用DHCP随机分配；第二，稳定版固件就好，别手痒点最新的内测推送，“版本更新后DLNA被改名/隐藏”这种事在论坛上见过不止一次；第三，多音源方案别一口气全上，先把DLNA跑通，体验到位了再加HA、AirConnect这些，不然排查问题时会很痛苦；第四，版权这条线不能越，NAS音乐库应该是你自己购买、抓轨或拥有授权的数字资产，拿来做个人归档和管理完全没问题，别把它变成传播盗版的中转站。
我自己现在日常用最多的，反而是最朴素的组合：minidlna做媒体服务，BubbleUPnP手机推流，外加HA定时播晨间歌单。AirConnect偶尔切到iPhone隔空播放时用。折腾到这一步，小爱在我家的角色已经彻底变了——不再是一个被会员曲库和试听限制绑住的摆设，而是我家音乐系统里一个稳定、可控的输出终端。你也按这个顺序来，应该能少走不少弯路。祝折腾顺利。
