一、蓝牙Mesh概述：技术起源、核心特性与传统对比
1.1 蓝牙Mesh是怎么来的？
说起蓝牙Mesh的起源，得先聊聊传统蓝牙的痛点。你想想看，传统蓝牙是一对一的——手机连音箱、耳机连手机，一个主设备最多带7个从设备。这在智能家居场景里根本不够用。
我记得2015年左右，我接手一个办公楼照明项目。客户要求用手机控制200多盏灯，每层楼还要能分组调光。当时用传统蓝牙根本做不了，最后被迫上了ZigBee。那会儿我就想，要是蓝牙能像ZigBee那样组网就好了。
2017年，蓝牙技术联盟（SIG）正式发布了蓝牙Mesh标准。说白了，它就是把蓝牙从「点对点」变成了「多对多」的网络。每个节点都能转发消息，消息可以在节点之间一跳一跳地传递。这样一来，覆盖范围就不再受单个设备的射频距离限制了。
核心认知：蓝牙Mesh不是一种新的蓝牙射频技术，而是在BLE（低功耗蓝牙）之上定义的一套网络层协议。它仍然使用BLE的物理层和链路层，但增加了消息转发、节点管理、安全加密等能力。
1.2 三大核心特性：自愈、多跳、低功耗
这三个特性，是我在实际项目中体会最深的。一个一个说。
自愈（Self-Healing）
什么叫自愈？就是网络里某个节点挂了，消息会自动绕路走。我做过一个仓库环境监测项目，部署了50多个温湿度传感器。有一次工人搬货时不小心碰掉了一个节点，结果网络照常运行，数据一条没丢。
为什么会这样？因为蓝牙Mesh用的是管理型泛洪（Managed Flooding）。每个节点都维护着一张「消息缓存表」，收到消息后先查表——如果已经转发过就丢弃，没转发过就继续广播。当某个节点离线时，它的邻居节点会检测到心跳超时，后续消息就不再往那个方向发了，自动选择其他路径。
避坑指南：我曾经以为自愈是「瞬间完成」的。实际上，节点离线检测需要时间（默认几十秒），而且消息重路由也需要几跳的收敛过程。在关键场景下，建议把心跳间隔调短一些，比如从默认的20秒改成5秒。
多跳（Multi-hop）
多跳是蓝牙Mesh的基石。每个节点既是终端设备，也是中继器。消息从源节点发出，经过若干中间节点转发，最终到达目标节点。
我习惯把多跳网络想象成「人传人」——你喊一句话，旁边的人听到了，他再喊给下一个人听。蓝牙Mesh也是这样，只不过它用TTL（生存时间）来控制消息能传多远。TTL=0时消息不再转发，默认一般是TTL=7，最多能传7跳。
实际项目中，一跳大概能覆盖10-30米（室内）。7跳就是70-210米，覆盖一栋楼绰绰有余。
低功耗（Low Power）
低功耗这个特性，说白了就是「省电」。蓝牙Mesh专门定义了两种节点类型：低功耗节点（LPN）和好友节点（Friend）。LPN平时深度睡眠，只在需要时醒来收发消息；好友节点帮LPN缓存消息，等LPN醒来再转发给它。
我做过一个智能门锁项目，用纽扣电池供电。如果不启用LPN模式，电池撑不过3个月。启用之后，续航直接拉到1年以上。嗯，这里要注意：LPN和Friend必须成对配置，而且一个Friend最多支持几个LPN，具体看芯片的内存大小。
| 节点类型 | 功耗 | 典型场景 | 注意事项 |
|---|---|---|---|
| 中继节点（Relay） | 较高 | 网关、灯控、插座 | 必须常供电 |
| 低功耗节点（LPN） | 极低 | 门锁、传感器、开关 | 需配对Friend节点 |
| 好友节点（Friend） | 中等 | 常供电的中继设备 | 内存占用随LPN数量增加 |
| 代理节点（Proxy） | 中等 | 手机/网关接入 | 支持GATT与Mesh协议转换 |
1.3 与传统蓝牙的对比
很多初学者会问：蓝牙Mesh和传统蓝牙到底有什么区别？我列个表，一目了然。
| 对比维度 | 传统蓝牙（BR/EDR） | BLE（低功耗蓝牙） | 蓝牙Mesh |
|---|---|---|---|
| 网络拓扑 | 星型（1对7） | 星型（1对多） | 网状（多对多） |
| 覆盖范围 | 10-100米 | 10-100米 | 数百米（通过多跳扩展） |
| 节点数量 | 最多7个从设备 | 理论上不限，实际受限于扫描 | 理论支持32767个节点 |
| 功耗 | 高（mA级） | 低（μA级） | 低（LPN模式可更低） |
| 数据传输 | 高速（2-3 Mbps） | 中速（1 Mbps） | 低速（主要用于控制/状态） |
| 应用场景 | 音频流、文件传输 | 穿戴设备、信标 | 智能照明、楼宇自动化 |
从这张表能看出来，蓝牙Mesh并不是要取代传统蓝牙或BLE，而是补足了它们在组网能力上的短板。说白了，传音频还得用传统蓝牙，传小数据用BLE，要组网控制就用Mesh。
重要提醒：蓝牙Mesh的消息传输速率很低，单条消息最多11字节有效载荷，而且有重传和确认机制。千万别用它传音频、视频或大文件。我见过有人想用Mesh传固件升级包，结果一个几百KB的包传了半小时还没传完——那是真踩坑了。
1.4 蓝牙Mesh的协议栈架构
聊完特性，咱们看看蓝牙Mesh的协议栈长什么样。我画了一张图，把各层的关系理清楚。
从这张图能看出来，蓝牙Mesh的协议栈分得很细。我重点说几个在实际开发中经常打交道的层：
- 网络层：负责消息的路由和中继。你配置TTL、选择是否开启中继功能，都在这一层。
- 下层传输层：负责消息的确认和重传。如果某个节点没收到ACK，它会自动重发。这个机制保证了可靠性，但也带来了延迟。
- 上层传输层：负责大消息的分段和重组。蓝牙Mesh单条消息最多11字节，超过这个长度就要分段发送。我遇到过一个问题：分段消息如果有一片丢了，整个消息都得重传。所以尽量把消息控制在11字节以内。
- 接入层：管理应用密钥。不同应用可以用不同的AppKey，实现安全隔离。比如灯控用AppKey A，门锁用AppKey B，互不干扰。
个人经验：刚开始做Mesh开发时，我总搞混NetKey和AppKey。后来我习惯这么记：NetKey是「门禁卡」，能进网络就行；AppKey是「房间钥匙」，不同房间用不同钥匙。一个节点可以有多个AppKey，但只能有一个NetKey。
1.5 小结
蓝牙Mesh的出现，解决了传统蓝牙在组网能力上的短板。它的自愈特性让网络更可靠，多跳机制扩展了覆盖范围，低功耗模式延长了电池寿命。虽然消息速率不高，但对于智能家居、楼宇自动化这类控制场景来说，完全够用。