1. 蓝牙Mesh网络基础：拓扑、节点角色与消息机制

各位工程师朋友，咱们开始聊蓝牙Mesh。说实话，我第一次接触Mesh时也有点懵——这跟经典蓝牙、BLE广播完全是两码事。但搞懂了它的网络结构，后面那些掉线重连、稳定性问题，其实都有迹可循。

蓝牙Mesh不是点对点通信，而是一个多对多的网络。每个设备都能转发消息，整个网络没有中心节点。这种设计天生就抗单点故障——你想想看，一个灯泡坏了，整个楼层的灯不会全灭。

蓝牙Mesh的拓扑，说白了就是节点互联的网状结构。每个节点都可以跟周围节点通信，消息通过中继一跳一跳传遍全网。

核心特征：

我在一个智能楼宇项目里遇到过这种情况：走廊尽头有个传感器，离网关隔了三堵墙。如果用传统BLE，早就断连了。但Mesh网络里，它通过中间两个灯泡做中继，数据稳稳地传到了服务器。这就是网状拓扑的价值。

蓝牙Mesh定义了四种节点角色。我习惯把它们比作一个团队：有人负责跑腿，有人负责站岗，有人负责对外联络。

我的经验：一个节点可以同时承担多个角色。比如一个常供电的灯泡，可以同时是Relay和Friend。但低功耗节点不能做Relay——它大部分时间在睡觉，没法帮别人转发消息。

Relay节点收到消息后，会重新广播出去。消息每经过一个Relay，TTL（生存时间）减1。TTL到0时，消息不再转发。我建议TTL初始值设7~10，太大容易造成网络拥塞。

手机、平板这些设备不支持Mesh协议栈，它们通过Proxy节点接入。Proxy节点在Mesh网络和BLE GATT之间做协议转换。说白了，手机连上Proxy节点，就能控制整个Mesh网络。

这类节点大部分时间在睡觉，每隔几百毫秒醒来一次，问朋友节点："有我的消息吗？" 有就收，没有继续睡。我做过一个温湿度传感器，用CR2032电池，Low Power模式跑了两年多。

Friend节点为Low Power节点缓存消息。Low Power节点睡觉时，Friend帮它收着消息。等它醒来，Friend再一次性交给它。这种配对关系叫Friendship。

注意：Friendship建立后，Friend节点不能随意退出。我曾经在项目里遇到过Friend节点重启导致Low Power节点丢消息的情况。解决办法是：Friend节点退出前，先发一条"我要下线了"的消息，让Low Power节点重新找朋友。

蓝牙Mesh的消息传递，用的是发布/订阅模型。不是A直接发给B，而是A发布消息到一个"主题"，订阅了这个主题的节点都能收到。

这个"主题"在Mesh里叫组地址或订阅地址。每个节点可以订阅多个地址，也可以向多个地址发布消息。

举个例子：

这种机制的好处很明显：新增设备时，只需要让它订阅对应的组地址，不用修改任何现有设备的代码。我在一个酒店项目里，后期加了30多个灯，配置一下订阅地址就完事了，不用动原来的逻辑。

避坑指南：我曾经遇到一个诡异问题——开关按下去，灯要等两三秒才亮。查了半天，发现是TTL设了63，消息在网络里绕了一大圈。后来把TTL改成5，响应时间降到200ms以内。所以，TTL不是越大越好，够用就行。

蓝牙Mesh的基础，说白了就三件事：网状拓扑让网络没有单点故障；四种节点角色各司其职，兼顾了覆盖、功耗和兼容性；发布/订阅机制让设备间解耦，新增设备不用改旧代码。

这些概念是后面所有实战内容的地基。搞懂了它们，你再看掉线重连、消息可靠性、网络优化这些话题，思路会清晰很多。嗯，咱们先把基础打牢，后面才好盖高楼。