BLE 5.0 升到 5.4：一次智能穿戴适配的踩坑记录

我们有一条出货量稳定的手表产品线，主控从只支持 Bluetooth 5.0 的旧平台换到标称 5.4 的新平台。立项时判断这是一次常规换代，实际做完用了三个月、六轮样机。下面是几个真正卡住进度的问题，以及最后的处理方式。

先分清"支持 5.4"支持的是哪一层

芯片规格书写着 Bluetooth 5.4，通常只说明控制器通过了对应版本的射频测试项。主机协议栈是否实现了新特性、认证列表覆盖到哪一版，需要单独核对。第一批样机的连接功能全部正常，但 PAwR（Periodic Advertising with Responses，带响应的周期广播）的响应时隙始终收不到数据，追到 HCI 日志才发现控制器侧状态机停在同步建立，主机层根本没有实现这条路径。

我们把控制器版本、主机协议栈版本、认证清单拆成三张表逐项打勾，再决定哪些特性可以进产品。版本号是能力上限，不是可用清单。

2M PHY 全开并不等于更快

5.0 引入的 2M PHY 把符号率翻倍，理论吞吐随之提高，代价是接收灵敏度大约下降 3 dB，链路预算同步缩水。我们最初把广播和连接全默认走 2M，实验室数据很好看。到了用户手上，手臂遮挡、表带转动手腕内侧这类场景的丢包率明显上升，重传把省下的时间又吃回去，实测有效吞吐只比 1M 高个位数百分比。

改法是按链路质量动态选速率：信号强时用 2M，RSSI 跌到阈值以下回到 1M，只有远距离抄表类场景才启用 Coded PHY（S=8 的长距离编码）。2M 与 Coded 在同一连接里互斥，二选一，这一点在参数配置表里要写死。

扩展广播撞上老机型的兼容断层

5.0 的扩展广播单包数据可以到 255 字节，比传统广播的 31 字节宽裕得多。我们把设备名、服务 UUID、厂商自定义字段一股脑塞进扩展广播，产线测试机上一切正常，因为那批测试机是当年新买的旗舰。用户手里的旧机型扫不到设备，回退逻辑没有写。

现在的广播分两层：主广播保持传统格式、只放必要字段，扩展广播作为补充，扫描端不支持时静默降级，不报错也不重试。广播集的数量同样要按控制器实际资源确认，规格允许的数量和固件真正开得出来的数量经常不一致。

连接子速率与实时数据流冲突

5.3 的连接子速率（Connection Subrating）允许在维持连接的前提下跳过部分连接事件，静态场景的功耗收益明显。我们在睡眠监测链路里开了它，静态心率的上报延迟从一秒级涨到八秒级，因为子速率因子把携带数据的事件整个跳过了。

定位办法是在 HCI 层给连接事件和数据指示打时间戳，两列时间对齐就能看出延迟来自哪一级。结论是子速率只给"确认设备在线"这类保活链路用，实时数据流不用。同时要处理与手机侧连接参数更新请求的仲裁，iOS 对最小连接间隔和从机延迟有固定的接受区间，超出区间直接拒绝，固件里要留降级路径，不能假设一次协商必成。

加密广播让配网流程返工

5.4 的加密广播数据要求广播内容加密、接收端先取得密钥。原有配网流程假设广播是明文，扫码即读，改造后密钥分发、密钥轮换、设备离线重连后的密钥同步都要重做一遍。

最后的取舍是把加密限定在配网完成后的状态广播上，配网阶段仍走明文加应用层校验。安全边界清楚了，改动量也从整条链路收缩到一段。

测试矩阵比参数表更重要

所有参数最终要在真机上验。我们拉了三十多款在售机型，按系统版本分三组，测扫描到连接的时延、MTU 协商结果、断连重连次数、OTA 升级成功率，功耗按一秒采样，把广播、连接、休眠三段拆开看。

同一套固件在不同机型上的连接成功率差异能到十几个百分点，只看平均值的测试报告会把这个差异完全掩盖。

结语

这次换平台真正的成本不在协议本身，而在把"规格支持"翻译成"产品可用"的那段验证工作。BLE 5.1 到 5.4 新增的方向查找、LE Audio 同步通道、子速率、加密广播，每一项都有明确的适用边界。穿戴设备的链路短、数据量小、对功耗和延迟都敏感，选了新特性就要为它准备回退路径。旧特性不会因为新版本发布而失效，稳定出货的产品线更值得把老路径守好。