为什么蓝牙大数据传输中我推荐MTU为498

因为一次 ATT Notification 中，有 3 字节固定开销：

• 1 字节：Notification Opcode
• 2 字节：Attribute Handle

所以有效载荷为：

ATT 有效载荷 = 协商 MTU - 3

原来 MTU 为 491：

491 - 3 = 488 字节
495 字节 HFT 分片 = 488 + 7

因此 HAL 必须发送两次 Notification。

改为 MTU 498：

498 - 3 = 495 字节

刚好能用一次 Notification 承载完整的 495 字节 HFT 分片。

这里的“一次”指一次 ATT Notification；底层仍可能拆成多个 ACL/空口数据包。前提是手机也支持并成功协商到 MTU 498。

 

但是不建议所有蓝牙协议都固定使用 498。

• 大数据传输（OTA、HFT、日志）：推荐 498，可减少 Notification 次数。
• 小命令/状态上报：收益很小，几十字节数据无需大 MTU。
• 广播数据：不使用 ATT MTU，设置 498 无影响。
• 经典蓝牙或 L2CAP CoC：使用不同的分包机制，不能直接套用。
• 资源受限设备：大 MTU 会增加 NimBLE 内存池和缓冲区压力。

对当前项目，建议将 498 作为本地首选最大 MTU，但保留动态兼容：

实际 MTU = min(本机支持值, 对端支持值)
实际单次载荷 = 实际 MTU - 3

因此，手机或手表只支持较小 MTU 时，HAL 仍需自动分片。498 最适合当前 495 字节 HFT 分片，不是所有 BLE 场景的通用最优值。