智能硬件 · 2026/5/24

从“油管收音机”到声播网络收音机：一个云端长音频播放器的产品化复盘

复盘声播网络收音机从个人工具到产品化系统的过程：ESP32-S3 播放器、手机网页、云端音频库、Wi-Fi/4G 配网、播放列表、定时闹钟和后台服务稳定性。

我最初想做的东西很简单：把一些适合“听”的长内容，从手机和电脑里解放出来，变成一台放在桌面上、上电就能自动播放的小收音机。

它内部经历过很多名字，比如“油管收音机”“阿里云盘音频播放器”“Podcast Audio”。真正准备产品化时，我把它统一成一个更准确的名字：声播网络收音机。

这个名字更接近它真正解决的问题：用户不用一直打开手机，也不用把蓝牙音箱绑在手机播放上；只要用手机完成设置，设备就能从云端音频库里自动播放长音频、播客、访谈、公开课和频道节目。

它解决的不是“怎么播放声音”，而是“怎么持续听内容”

手机当然可以听音频，但手机也是最容易让人分心的设备。你本来只是想听一个访谈，打开手机后很容易被消息、短视频、社交软件带走。

普通蓝牙音箱也能播放，但它通常依赖手机作为播放源。手机离开、断连、省电策略介入，播放体验就会被打断。

声播网络收音机的思路是把整个过程拆开：

• 手机负责搜索、订阅、整理播放列表和远程控制。
• 云端音频库负责保存音频和播放清单。
• 桌面设备只负责稳定播放。

这样设备就更像传统收音机：上电、联网、自动播放。手机只是遥控器和内容管理入口，而不是持续播放的负担。

用户实际看到的两个入口

为了让终端用户少接触后台概念，整个系统只保留两个用户入口。

第一次使用时，用户连接设备热点：

podcast-setup

然后打开：

http://192.168.4.1

这个页面用于配网、选择联网方式、复制设备绑定码，以及必要时恢复出厂设置。

日常使用时，用户只需要打开手机网页：

https://podcast.showx.me

在这个网页里可以登录账号、连接云端音频库、管理设备、搜索内容、订阅频道、生成播放列表、调整音量、暂停播放、下一首、设置定时和闹钟。

整体架构

这套系统分成四层：

1. 设备端：ESP32-S3、MAX98357A 功放和喇叭，可选 ML307R 4G 模块。
2. 本地控制服务：负责账号、云盘授权、搜索、下载、音量优化、上传、播放列表和设备控制。
3. 手机网页端：面向最终用户的控制台。
4. 公网接入层：通过 Cloudflare Named Tunnel 把公网请求转发到本地控制服务。

生产链路可以简化理解为：

手机浏览器
  -> podcast.showx.me
  -> Cloudflare Named Tunnel
  -> 本地控制服务
  -> 云端音频库 / ESP32 设备

这个架构的重点是：用户不需要知道后台服务在哪里运行，也不需要操作桌面端程序。对用户来说，它就是一个网页和一台设备。

设备端：一台尽量“像收音机”的 ESP32 播放器

当前定型固件版本是 V1.7。设备端基于 ESP32-S3，音频输出使用 MAX98357A I2S 数字功放。

目前保留了两个硬件接线版本，功能完全一致，只是 I2S 引脚不同：

版本 A：GPIO15/16/7
BCLK -> GPIO15
LRC  -> GPIO16
DIN  -> GPIO7

版本 B：GPIO2/3/4
DIN  -> GPIO2
BCLK -> GPIO3
LRC  -> GPIO4

两个版本都支持：

• 中文强制门户配网页。
• 设备绑定码复制。
• Wi-Fi 重新配置。
• 恢复出厂设置。
• 播放列表优先播放。
• 单曲循环和列表循环。
• 断点续播。
• 播放 / 暂停 / 下一首 / 音量控制。
• 定时播放、限时播放、定时关闭和闹钟播放。

V1.7 重点修复的是跨网络环境换 Wi-Fi 的问题。早期版本在用户把设备从家里拿到公司后，重新配网容易出现扫描不到热点、保存新 Wi-Fi 后仍使用旧配置、必须恢复出厂设置才能重新配置等问题。V1.7 把 Wi-Fi 保存和连接流程交还给 WiFiManager 完整处理，并在保存后给底层驱动足够时间落盘和重启，因此换网稳定性明显提升。

Wi-Fi 与 4G：让设备尽量自己联网

有些使用场景没有稳定 Wi-Fi，比如临时空间、展台、户外或一些公司网络环境。因此设备预留了 ML307R 4G 模块接入能力。

配网页里可以选择联网方式：

• 自动：优先 Wi-Fi，Wi-Fi 不可用时尝试 4G。
• 仅 Wi-Fi：只使用 Wi-Fi。
• 仅 4G：只使用 4G。

更关键的是，无论设备当前走 Wi-Fi 还是 4G，都会保留 podcast-setup 配网热点。用户可以随时连回设备页面修改网络，而不需要拆机、刷固件或清空所有配置。

手机网页：把“找内容、编排内容、播出内容”放到一个界面

手机端最终被设计成一个面向普通用户的控制台，而不是工程调试面板。页面主要承担三件事：

第一是发现内容。用户可以搜索公开内容，也可以订阅频道。频道订阅后，系统会定期检查更新，把新内容整理到用户自己的云端音频库中。

第二是编排内容。用户可以把音频加入当前播放列表，调整顺序，移至顶部，删除，也可以设置单曲循环或列表循环。

第三是控制设备。用户可以选择账号下绑定的不同设备，并控制当前设备播放、暂停、下一首和音量。

后期又加入了更接近收音机日常使用的功能：

• 播放一段时间后自动停止。
• 指定时间关闭。
• 指定时间播放。
• 闹钟播放。
• 闹钟按星期启用。
• 闹钟触发时从低音量缓慢升高，避免突然吵醒用户。

这些功能看起来不复杂，但会显著影响“每天是否真的愿意用”。

云端音频库：让音频属于用户自己

系统会把音频保存到用户自己的云端音频库中，而不是让设备直接依赖临时在线播放链接。

这样做有几个好处：

• 播放列表更稳定。
• 用户可以管理自己的音频文件。
• 设备不需要理解复杂内容源，只要按清单播放云端音频。
• 后台可以在上传后清理本地缓存，避免服务端硬盘被多个用户下载内容塞满。

这也是从个人工具走向多用户服务时必须处理的问题。下载、音量优化和上传都可以是后台能力，但用户文件上传完成后，本地临时文件应及时删除，避免运营端无限扩容。

音量处理：下载时优化比播放时硬压更可靠

长音频来源不同，音量差异很大。有些音频本身增益过高，直接播放会破音；有些音频偏小，用户又会把设备音量调得很高。

最终更合理的方案是在后台下载后做音量优化，让进入云端音频库的文件本身更适合小功放和桌面喇叭播放。设备端仍保留实时音量控制，但不把所有音质问题都压到 ESP32 播放时处理。

这类小设备的音频目标不是发烧音质，而是长时间可听、不刺耳、不频繁破音。

商业化时要隐藏复杂性

如果作为商品交付，用户不应该看到“下载、转码、上传、隧道、后台服务、MQTT、D1”这类工程概念。

对用户来说，流程应该是：

1. 设备通电。
2. 手机连接 podcast-setup。
3. 打开 192.168.4.1 配网。
4. 复制绑定码。
5. 打开 podcast.showx.me 绑定设备。
6. 搜索或选择音频。
7. 加入播放列表。
8. 设备自动播放。

后台做了很多事，但产品表达要尽量收敛：手机设置，云端保存，设备播放。

生产运维：网页服务必须像产品一样常驻

这套系统一开始有桌面 GUI 工具参与，后来逐步迁移为后台服务。原因很简单：只要用户关闭桌面 GUI，手机网页就不能正常操作，这显然不适合作为商业产品。

当前本地控制服务已经做成开机服务，并加入：

• 开机自动启动。
• 异常退出自愈。
• 健康检查失败后自动重启。
• 日志轮转。
• 上传完成后清理本地缓存。

公网入口也从临时 quick tunnel 迁移到 Cloudflare Named Tunnel，并作为常驻服务运行。这样 podcast.showx.me 才能接近商业服务所需要的稳定性。

售后边界也要提前写清楚

这类产品既有硬件，也依赖网络、云盘和公开内容源。如果不提前定义边界，售后会很难做。

建议对外承诺：

• 配网指导。
• 设备绑定指导。
• 云端音频库授权指导。
• 播放列表设置指导。
• 常见硬件和联网问题排查。

不建议承诺：

• 第三方内容源永久稳定可用。
• 所有公开视频都一定能保存成音频。
• 用户网络环境一定支持。
• 用户云盘空间一定充足。
• 非授权内容的保存与传播。

对外表达也应避免“无版权限制下载”“绕过平台规则”“全网随便下载”这类说法。更稳妥的表达是：支持公开内容检索，适合用户自有或已授权内容，音频保存在用户自己的云端音频库中。

最终产品定义

声播网络收音机不是一个传统蓝牙音箱，也不是一个单纯下载工具。它更像是一套“长音频收听工作流”被压缩进了一台桌面设备里：

• 手机负责轻操作。
• 云端负责保存和同步。
• 后台负责搜索、整理和维护。
• ESP32 负责像收音机一样稳定播放。

它适合听播客、公开课、访谈、商业分析、科技解读和频道节目，也适合放在书桌、卧室、厨房、办公室里做长期背景播放。

我喜欢这个项目的一点是，它不是为了让人更频繁地看屏幕，而是让好内容从屏幕里出来，变成一个可以安静陪伴的声音设备。