微信小程序蓝牙通信MTU优化：突破20字节限制的实战指南

1. 从20字节的“堵车”说起：为什么你的蓝牙数据总断包？

最近在折腾微信小程序的蓝牙功能，估计不少朋友都踩过和我一样的坑：手机端接收数据，只要数据包稍微大一点，超过20个字节，好家伙，数据就开始“断片”了。你明明发送的是一段完整的信息，比如一个传感器的完整读数，结果到小程序这边，硬生生被拆成了好几截，还得自己费劲去拼起来，不仅麻烦，还容易出错。

我一开始也百思不得其解，以为是自己的代码逻辑有问题，或者蓝牙模块不稳定。查了一圈资料，又抓包分析，最后才搞明白，这其实不是bug，而是一个“特性”。蓝牙低功耗（BLE）协议在设计之初，为了极致地省电和保证连接稳定性，对单次传输的数据量做了严格的限制。这个限制，就是我们今天要聊的主角——MTU（Maximum Transmission Unit，最大传输单元）。

你可以把MTU想象成一条数据传输的“高速公路车道”。默认情况下，这条车道比较窄，一次只能通过一辆很小的“数据车”（默认通常是23字节）。这23字节里，有3个字节是蓝牙协议自己用的“车头”（Header），用来指挥交通，真正能装你“货物”（应用数据）的“车厢”，就只有20个字节了。所以，当你发送的数据超过20字节时，系统就必须把它拆分成好几辆小车，一辆一辆地通过。如果接收端处理不及时，或者拆分、组装的规则没对上，就会出现我们看到的“断包”现象。

这在小程序开发里尤其常见，因为我们经常需要传输一些稍微复杂的数据，比如一串JSON、一个包含多个参数的控制指令，或者一段简短的固件升级包，很容易就超过20字节。所以，理解并优化MTU，是做好小程序蓝牙通信的必修课。接下来，我就把自己趟过的路、踩过的坑，以及最终怎么把这条“车道”拓宽的实战经验，毫无保留地分享给你。

2. MTU到底是什么？不只是数字那么简单

2.1 拆解MTU：协议栈里的“集装箱”规格

MTU，最大传输单元，听起来挺技术，其实道理很生活化。我们继续用运输来打比方。你要把一批货物（你的应用数据）从A点（手机）运到B点（蓝牙设备，比如智能手环）。

• 货物（Application Data）：就是你想发送的实际内容，比如 {“cmd”: “turnOn”, “value”: 100}。
• 集装箱（ATT PDU）：蓝牙协议里，真正在物理空中传输的数据包格式，叫做ATT协议数据单元。MTU指的就是这个“集装箱”的最大容量。
• 车头（L2CAP Header）：集装箱装上卡车（L2CAP层）运输时，还需要一个车头信息，通常是4个字节，用来标识通道、长度等。
• 最终包裹（链路层数据包）：卡车最后还会被包进一个更外层的包裹里，加上地址、校验等信息，这个包裹的总大小是有限的（比如经典的27字节）。

所以，关键路径是这样的：你的应用数据要装进ATT集装箱，集装箱加上L2CAP车头组成卡车，最后打包成链路层包裹发送出去。MTU的大小，直接决定了你的“ATT集装箱”能有多大。默认的23字节MTU，减去3字节的ATT操作码等开销，正好剩下20字节给你装货。

2.2 微信小程序里的MTU现状与限制

在微信小程序（以及很多基于小程序框架的跨平台方案，如uni-app）的早期版本中，开发者对这个“集装箱”规格是没有话语权的，系统给你用多大的，你就得用多大的。这就是为什么我们普遍会遇到20字节这个天花板。

但是，从微信客户端基础库版本2.11.0开始，官方开放了一个至关重要的API：wx.setBLEMTU（在uni-app中是 uni.setBLEMTU）。这相当于给了我们一把“扩容”的钥匙，允许我们在一