一个失眠程序员的深夜实验：用坏掉的音箱造了个局域网播放器

「我每晚睡前都要听音乐，这是我从小到今唯一固定的习惯。」一位刚学完 Go 语言的开发者，因为常用的小音箱突然坏了，决定自己动手造一个替代品。他没有选择买新的，而是打开编辑器，用 WebSocket 写了一个局域网音频流方案。

这个看似冲动的决定，暴露了一个被忽视的需求：现有产品解决不了「睡前音乐」这个具体场景的痛点。而他选择的技术栈——Go 语言加 WebSocket——背后是一套清晰的取舍逻辑。

从习惯断裂到动手解决

事情始于一年前。作者每天睡前依赖的小音箱突然无法连接，这个从童年延续至今的仪式面临中断。市面上买不到完全贴合需求的替代品，于是他产生了一个想法：为什么不自己做一个？

这个决定有几个前置条件。他当时刚完成《Tour of Go》《Let's Go》《Let's Go Further》三门课程，正在读《100 Go Mistakes and How to Avoid Them》。Go 语言的语法和并发模型刚在脑子里形成体系，需要一个实战项目来固化。

另一个动机是逃离 JavaScript 生态。「Node.js、React、Next.js 那一套已经太多了」，他写道。技术选型在这里带有明显的情绪因素——不是比较后的理性选择，而是对复杂前端工具链的疲惫反应。

但核心问题还没解决：音频流用什么协议传？

为什么选 WebSocket：一个非最优但够用的答案

作者坦承，选择 WebSocket 并非经过充分调研后的结论。「有这个想法的时候，WebSocket 就是第一个跳进我脑子里的东西，甚至在我开始写代码之前就想好了。」

这个直觉背后有两层技术考量。第一，他需要按顺序传输音频帧（PCM 数据块），而 WebSocket 基于 TCP，天然保证数据包的有序到达。第二，他对 WebSocket 已有一定信心，「虽然可能不是最佳选项，但这是我手头有的、有把握的东西。」

项目做到一半时，他才第一次听说 WebRTC。研究后发现，UDP 的无连接特性会导致丢包和乱序，这对 raw PCM 流是致命的——「丢一个数据块，要么出现静音，要么出现 glitch」。而 WebRTC 的设计场景是浏览器之间的点对点通信，与他的需求（服务器向多个局域网客户端广播）并不匹配。

「WebSocket 够用了。有时候这就够了。我不想过度工程化。」这句话概括了他的工程哲学：在正确性和交付之间，选择能工作的最小方案。

技术盲区与诚实姿态

作者在文中多次强调自己的知识边界：「我之前根本不知道 WebRTC 是什么」「PCM、WebRTC 这些术语都是做项目时现学的」「如果我说错了什么，评论区直接指出来。」

这种坦诚在技术写作中罕见。通常开发者倾向于展示完整的知识图谱，而非暴露学习过程中的认知断层。但正是这种姿态，让文章具有参考价值——它记录了一个真实的技术决策过程，而非事后美化的逻辑重构。

从 PCM 编码到局域网广播架构，每个技术点都是需求驱动的即时学习。作者没有为了「正确」而预先研究所有选项，而是让问题牵引知识获取。这种路径对独立开发者具有可复制性：先启动，再填补，而非先完备，再动手。

这个实验的真正价值

表面上看，这是一个用现有技术快速解决个人问题的案例。但更深层的启示在于：消费级硬件的故障，正在推动越来越多的用户走向「自造」而非「购买」。

作者的音箱坏了，他没有搜索「2024 最佳睡前音箱」，而是评估了自己的技术储备，判断可以在合理时间内产出可用方案。这种决策模式成立的前提是：开发工具的门槛持续降低，个人项目与商业产品的体验差距在缩小。

WebSocket 在这里扮演了一个关键角色——它足够简单，不需要深入音视频协议栈；又足够可靠，能支撑一个每晚使用的场景。作者的选择不是最优解，但是一个「可执行的最优解」，这对资源有限的个人项目至关重要。

如果你也有固定到无法妥协的习惯，和刚好够用的技术储备，下一个被造出来的可能不是音箱，而是别的什么被现有产品忽视的需求。