9 路摄像头挂在 Banana Pi M5 上跑了大半年，从 v0.6 开始累积的工程债到了不得不还的时候。/api/cameras 接口在 9 个录制器全部启动的过程中要卡 14.9 秒——不是遍历慢，是 cm.mu RWMutex 在阻塞，任何读操作都进不来。ONVIF 摄像头添加还得手动填 IP，家里装了 CW500、DS-2CD2047G2 这类设备之后，每多一台就要开一次终端，不可持续。FFmpeg 作为 NVR 唯一的第三方二进制依赖，每次部署都要确认装没装，树莓派上还要操心硬件编码器版本。更扎心的是，Xiaomi 的那几个旧设备——Dafang、Xiaofang、Aqara G2——因为走了 TUTK 协议，一直没法接入。这些问题都不是新技术挑战，是工程债，v0.9 一次性还了。

上一篇讲了 v0.3.0 有什么。这篇讲为什么——本版有三个看似随意、背后有具体工程取舍的决定：Docker 网络模式如何决定 scanner 的探测保真度、TLS 证书链采集为什么能用一个核心覆盖 8 个协议、L2 拓扑为什么需要三个 MIB 才拼得起来。逐个拆。

接手一个不熟悉的局域网，第一件事是搞清楚里面有什么——办公室、机房、家里几个网段混接，没人留下文档，交换机上连着一堆没人叫得出名字的 MAC。MiBeeSteward 就是干这件事的：扫一遍网络，告诉你有哪些设备、它们是什么、它们之间怎么连的。

在 MiBee NVR 监控大屏项目里，前端到底给 16 路摄像头拉 H.264 还是 H.265 流？这是个看似简单但越挖越深的问题。H.265 同画质码率只有 H.264 的一半，带宽和存储都省；但网上不少资料又说"H.265 浏览器支持差、Firefox 不支持、要装扩展"。到底哪些说法还成立？

P2P 传输栈里，libp2p 长期是默认选项——但它的协议栈庞大、配置面广，每次新项目都要在 tcp/quic/webrtc/noise/yamux/identify/kad/relay/dcutr 一长串 feature 里挑组合。iroh 是 Rust 生态里走另一条路的库：只做 QUIC + dial-by-public-key + NAT 穿透，把传输层收敛到很小，再在它上面叠加 blobs/gossip/docs 三个可选模块。2026 年 6 月 15 日 n0 发布 iroh 1.0，slogan 是「Dial Keys, not IPs」，经过 4 年开发、65 个预发布版本后第一次稳定。

2023 年 8 月，HashiCorp 把 Terraform、Vault、Consul 等全部核心产品从 MPL 2.0 改成 BSL 1.1。社区炸了，一个月后 Linux 基金会牵头 fork 出 OpenTofu。本以为故事到此为止——结果 2024 年 4 月 IBM 宣布 64 亿美元收购 HashiCorp，2025 年 2 月完成交割，HashiCorp 变成 IBM 旗下的 Red Hat 业务单元。改许可证的 OSS 公司不但没衰落，反而成了被并购的标的。

2017 年 9 月，React 一夜之间从 BSD+Patents 改成了 MIT。原因是 Apache 软件基金会把 React 的许可证列入「禁止依赖」清单，WordPress 母公司 Automattic 当场宣布放弃基于 React 重写界面——Facebook 顶不住整个生态施压，妥协了。七年后的 2024 年 3 月，Redis 把核心从 BSD 3-Clause 改成 RSALv2+SSPL 双协议，AWS、Google、Oracle 一周内联合 fork 出 Valkey 把它替代了。

上一篇讲了 v0.2.0 有什么。这篇讲为什么这么设计——分布式一致性是这个版本最重的部分，几个看似随意的决定背后都有具体的取舍。 要解决的问题很明确：center 只能看见自己所在的 LAN，但用户有多个 LAN。把 center 扔到每个网段不现实，于是有了 mibee-agent——一个只做「扫本地 + 报 center」的二进制。但 agent 一上，立刻带出一串协议问题：怎么上报、怎么对账、怎么判定掉线、怎么不把 center 写爆。下面逐个拆。

v0.1.0 发布的时候我写了一句：它能回答「网络上有哪些设备、它们是什么、它们之间什么关系」。但说实话，v0.1.0 只答好了前半句——而且只限于 center 所在的那一个 LAN。 工作室的真实场景是：办公室一个网段、机房一个网段、家里跑测试机又一个网段。center 坐在办公室，机房的摄像头它根本看不见。要让 center 去扫机房，得跨子网穿透，要么开 SNMP 路由转发，要么干脆把 center 搬过去——两个都不优雅。

系列第二篇用 edge-tts 出了配音，第五篇梳理了 TTS 技术发展史。本篇是收官篇——当你的项目不满足于 edge-tts 时，市面上 31 款 TTS 引擎和服务该怎么选？ 我们把选型路径分成三层：免费开源引擎（本地运行、零授权费但有 GPU 部署成本）、免费云服务（开箱即用但有额度/限流约束）、付费服务（开箱即用 + SLA + 高级能力）。这并非严格的层级递进——开源引擎搭配自建 GPU 可能比付费云服务长期更便宜，而付费云服务的开箱便利性又是自部署无法比拟的。选择取决于你的预算、人力、时间三者的权衡。