都叫蓝牙 Mesh，自定义组网、SIG Mesh 和小米 Mesh 到底是什么关系？
自定义 Mesh、Bluetooth SIG Mesh 和小米 Mesh 是什么关系？从组网、安全、设备模型、米家接入与断网控制，讲清标准互通的条件和实际选型差异。
做蓝牙设备和网关，迟早会遇到一个问题：到底选哪一种 Mesh？
芯片厂说自己有 Mesh SDK，模组厂说支持 SIG Mesh，产品经理希望接米家，团队手里可能还维护着一套已经用了几年的私有广播协议。几个人坐下来讨论，嘴里说的都是 Mesh，想解决的却未必是同一个问题。
在前面的 Matter 网关文章里，我从设备接入的角度讨论过私有协议和 SIG Mesh。这次把蓝牙这一侧单独展开，先回答最基础、也最容易影响选型的问题：自定义 Mesh、SIG Mesh 和小米 Mesh，并不是三个完全平行的协议选项。
自定义 Mesh 说的是谁设计和控制这套组网机制；SIG Mesh 指向一套公开的蓝牙网状网络标准；小米 Mesh 则还包含设备怎样进入米家、怎样被识别、怎样通过网关和平台使用。把这几个层次分开，后面的选择会清楚很多。
先弄明白，你说的“Mesh”究竟有什么能力
假设客厅有一个控制器，卧室有一盏灯。距离近时，控制器直接发消息，灯收到后执行，这不难。
但如果隔了几堵墙，消息到不了呢？这时我们希望走廊里的设备能帮忙转发，让消息经过其他节点到达卧室。网状组网讨论的，就是这种多节点传递和协作的能力，以及为此需要的寻址、转发和网络管理。
这里有一个常见误会：一次广播能让很多设备收到，并不意味着已经做出了 Mesh。
一套自定义 BLE 广播协议，如果只是控制器发、周围设备收，没有多跳转发机制，它仍然是广播控制方案。它可能很适合单个房间，也可能开发起来很省事，但不能因此期待它自动把消息送到无线覆盖之外。
反过来，产品包装上写着 Mesh，也不意味着每台设备都会帮别人转发。节点承担什么角色、是否常供电、固件有没有启用中继，都会影响实际网络。
所以，讨论方案之前，我会先问：它究竟是直连、广播，还是支持多跳转发？如果支持转发，哪些节点负责转，网络又怎样避免一条消息被无限重复？
自定义 Mesh：自由度高，责任也跟着回来
“私有 Mesh”没有一份统一的技术规格。不同厂商可以设计完全不同的报文格式、转发规则、设备地址和入网流程。一个方案的表现，不能拿来代表所有私有 Mesh。
它的价值很好理解。如果设备、控制器和 App 都由自己掌握，功能也比较集中，就可以围绕具体需求设计协议。比如只做一类照明产品，不必一开始就覆盖大量通用设备模型；已经出货的产品，也可能需要继续兼容原有协议。
但加入中继以后，需要考虑的事情会明显增加：
- 同一条消息从几个方向到达，怎么识别重复、避免重复执行？
- 转发几次就应该停止，哪些设备适合承担中继？
- 新设备怎样证明身份、拿到密钥，被移除的设备还能不能控制网络？
- 断电重启后，怎样继续防止旧消息被重放？
- 多台设备同时上报，或一组灯同时响应，怎样控制无线流量？
这些事情可以由自己的团队实现，也可以购买模组厂已经做好的私有方案。后者减少了开发量，却会把一部分长期依赖转移到供应商身上：网关能不能换、固件能不能维护、协议能不能拿到，都要事先谈清楚。
因此，私有 Mesh 并不天然更快、更便宜，也不天然不安全。它是否合适，取决于具体实现、产品边界和维护能力。只比较“点亮第一盏灯需要几天”，往往会漏掉后面的几年。
SIG Mesh：把组网、安全和设备行为放进共同规范
通常所说的 SIG Mesh，就是 Bluetooth SIG 制定的 Bluetooth Mesh 标准。它基于 Bluetooth LE，但不是把普通蓝牙连接一条条串起来。
标准覆盖的内容也远不止转发消息。它规定了设备入网、地址、消息传递、安全机制，以及应用层怎样描述和操作设备等内容。Bluetooth SIG 的 Mesh 入门文档对此有比较完整的介绍。
对开发者而言，可以先抓住三件事。
入网之后，还要配置设备怎样工作
Provisioning 可以理解为把未入网设备安全地纳入网络，分配地址并建立必要的安全信息。之后还要配置应用密钥、模型绑定、发布和订阅等关系。
这也是为什么“已经发现设备”“已经添加设备”和“已经能控制设备”不是同一个状态。无线层面看得见它，不代表它已经被授权接收这条控制消息。
能中继消息，不代表能读懂应用内容
SIG Mesh 区分网络密钥 NetKey 和应用密钥 AppKey。前者让节点参与相应子网的网络层处理；后者用于保护具体应用消息。
这种分层让节点可以承担网络转发职责，而不必掌握所有应用的控制权限。例如，一台设备能帮灯光消息中继，并不能由此推断它也有权限控制这些灯。
标准提供了这些机制，产品仍然需要正确地配置、保存和更新密钥。用了标准协议，不会自动消除实现和运维上的问题。
设备模型，让“开灯”有共同的含义
Generic OnOff、Light Lightness、Light CTL 等标准模型，分别提供开关、亮度、色温等功能相关的定义。设备双方不只是收到了一串字节，还能按照共同规则理解消息和状态。
与此同时，SIG Mesh 允许厂商定义 Vendor Model，承载标准模型没有覆盖的功能。
这意味着：应用层有私有命令，不等于底层就是一套私有 Mesh。 一个产品完全可以使用标准的 Mesh 网络与安全机制，同时用厂商模型实现自己的功能。判断方案时，要问清楚“私有”到底发生在哪一层。
采用 SIG Mesh，为什么也不能保证买回来就互通
我在前面的网关文章里强调过标准模型对跨厂商接入的价值。这里需要补充一个前提：这种价值要通过具体产品的能力和配置才能兑现。
设想两盏灯都写着“支持 SIG Mesh”。第一盏把基础开关能力放在标准模型里，第二盏还有一组需要厂商模型才能调用的特殊效果。通用控制器即使能控制基础开关，也未必能理解第二盏灯的全部功能。
另外，还需要有办法将设备纳入自己管理的网络，配置正确的密钥、模型和订阅关系。产品使用了标准，并不等于厂商必须向任意第三方控制器开放其全部配网和管理能力。
判断互通，我更愿意分成三步：
| 要确认的事 | 真正需要核对的内容 |
|---|---|
| 能否加入并参与网络 | 配网方式、管理权限、密钥和所需节点功能 |
| 能否完成指定操作 | 双方支持的模型、消息、状态与配置是否匹配 |
| 能否出现在目标平台并长期使用 | 平台接入、设备身份、功能映射、固件维护与支持范围 |
Bluetooth SIG 的入门文档也专门讨论了可选功能、配置灵活性与互操作之间的关系，并介绍了用于进一步约束设备行为的 Bluetooth NLC 设备配置文件。标准提供共同基础，产品级兼容性仍要针对目标功能验证。
小米 Mesh：标准机制之上，还有米家的接入体系
把小米 Mesh 理解成一套与 SIG Mesh 完全无关的无线协议，会把问题看偏。
在小米公开的蓝牙 Mesh 接入开发文档中，明确区分了两套描述：一套是 SIG 的 Mesh 模型与消息；另一套是小米定义的 MIoT Spec，用于描述产品的服务、属性和操作。网关负责两者之间的转换。
文档中的色温灯示例，既包含 Generic OnOff Server、Light Lightness Server 等标准模型，也包含小米自己的模型。这个例子很好地说明了：标准 Mesh 和生态扩展可以同时出现在一台设备里。
不过，这是一份较早的接入文档，不能把里面的芯片清单和操作步骤直接当成今天的开发要求。小米现行的 BLE Mesh 基础知识仍然介绍了网关在 Spec 与 Mesh 消息之间的转换，也列出了产品方案模板、固件配置和属性上报等要求。
对一个产品来说，“采用 SIG Mesh”和“接入米家”因此是两个需要分别完成的目标。前者回答设备采用什么技术基础，后者还要解决产品身份、平台定义、配网绑定、网关支持和功能展示等问题。
给普通 SIG Mesh 设备换一个名字，不会让它自动出现在米家里。 同样，买到一盏米家蓝牙 Mesh 灯，也不能仅凭这个标签，就承诺它能被自己的通用 Mesh 网关完整接管。
如果准备做米家版本，应在选芯片和写业务代码之前，就确认目标品类当前支持什么接入方案、能取得什么 SDK，以及目标网关支持哪些功能。这会直接影响产品设计，通常不是发布前再补一个接口就能解决。
“不用网关也能用”和“断网还能用”，要拆开问
这两个问题，经常和 Mesh 混在一起。
从标准协议的角度看，已经正确配置的 SIG Mesh 节点可以在本地交换消息，并不要求每一条开关指令都先去互联网云端。这里的前提，是对应功能确实在节点和本地配置中实现。
到了具体产品，就要看控制路径。小米现行 BLE Mesh 文档说明，远程控制需要 Mesh 网关；没有网关时，可以根据需要开发蓝牙直连控制。这里的“可以开发”，并不代表每一款已上市产品都支持同样的直连能力。
同一份文档还说明，非低功耗设备之间可以中继 Mesh 消息，但在其描述的方案中，设备之间不能相互控制。中继是帮助消息到达，控制还需要对应的应用能力。 这项说明也不宜被扩大成所有小米产品、所有版本永远相同的限制。
实际选购或开发时，我会把测试分开：
- 只断互联网，保留路由器、网关和设备供电，本地控制与自动化是否继续工作？
- 关闭网关，实体开关、设备间联动或手机近距离控制还能保留哪些功能？
- 设备和网关重启后，状态与控制关系能否正确恢复？
三种测试对应不同故障，不能用一次“断网后还能开灯”，就宣称整套系统完全不依赖网关或云端。
也别急着用节点数和延迟给三者排名
“哪个能带更多设备”“哪个响应更快”，是合理的问题，但只有 Mesh 的名字，还不足以回答。
SIG Mesh 的经典转发方式是 Managed Flooding，也就是受管理的泛洪转发。它不是让所有设备无条件地把所有包一直重复下去，还涉及中继配置、TTL、消息缓存等控制。Mesh 1.1 又引入了 Directed Forwarding，可以通过路径相关机制改善转发效率；实际产品是否支持并启用，仍要看协议栈和配置。
电池设备也不应直接被当成随时工作的中继。标准的 Low Power 与 Friend 机制，让低功耗节点减少持续接收，借助 Friend 节点暂存消息。节电方式会影响消息到达的时机，不能只谈电池寿命，不谈交互需求。
相比一个孤立的“最大节点数”，我更关心设备分布、上报频率、中继数量、重传配置和业务负载。十几台设备高频上报，与大量灯具偶尔接收一次组播命令，是两种不同的网络压力。
所以，本系列后面会把性能问题放进具体场景：怎样布置设备、发送什么消息、统计什么结果。没有共同的测试条件，就先不做谁更快、谁更稳的排名。
真正选型时，先确定自己要掌握什么
把前面的关系放在一起，可以得到一张更实用的对照表：
| 方向 | 主要解决什么 | 需要承担或确认什么 |
|---|---|---|
| 自定义／私有 Mesh | 围绕自己的产品需求定义通信与组网 | 具体协议质量、安全、维护、供应商依赖，以及跨方案接入成本 |
| SIG Mesh | 用共同标准处理组网、安全与设备模型 | SDK 和产品能力、模型匹配、配网管理、配置及实测互通 |
| 小米 Mesh 接入方案 | 让符合要求的设备进入米家使用体系 | 当前平台流程、产品定义、SDK、身份与绑定、目标网关和功能支持 |
这张表不是三选一。有的产品采用 SIG Mesh，再按米家的要求实现生态接入；有的产品采用 SIG Mesh，但网关和应用完全自己管理；也有产品因为存量兼容和特定需求，继续维护私有方案。
对我们正在做的 Mesh 转 Matter 网关来说，我仍然看重标准模型带来的清晰边界：先明确蓝牙侧怎样描述设备，再实现 Matter 侧的设备与状态映射。但这种映射需要处理功能范围、状态变化和异常恢复，并不是看到模型名字相似，就已经完成了桥接。
如果目标是接入现成的米家设备，第一步应确认设备允许的接入方式和可用能力；如果设备固件也由自己开发，就可以从模型、密钥管理和网关接口开始统一设计。这两个起点，决定了完全不同的工作量。
下一篇从私有方案往下拆：从一条自定义蓝牙广播，到一个真正能多跳转发的 Mesh，中间到底要补哪些东西？ 先把重复消息、转发范围、确认和安全这些问题摆出来，再谈它值不值得自己做。
如果你也在做蓝牙设备、照明控制或网关，可以带着具体场景来交流：联系我。设备数量、供电方式，以及希望接入的平台，会比一句“我想做 Mesh”更容易把问题聊清楚。