模型
蓝牙 Mesh在 BLE 物理层之上定义泛洪与可控中继，使用发布/订阅与模型（Model）描述灯、传感器等行为。配网（Provisioning）通过设备密钥与应用密钥分层；大规模网络需规划中继节点密度与延迟。
网关
蜂窝网关作为 Mesh 与云端桥梁，应缓存离线指令并做协议转换；出口带宽通常远大于 Mesh 侧，注意突发上报。
对比 Thread
二者均为近场 mesh，选型看生态、芯片供应与互操作需求。
规模、延迟与可靠性
Mesh 网络泛洪与受控中继在节点数上升时，控制面与数据面延迟都会增加，需通过中继布局、子网划分与 TTL 限制避免广播风暴。关键指令应使用可靠消息模型并确认重传；照明类应用可容忍更高延迟，安防与工业控制需更严格上限。配网密钥分发与撤销流程要可审计，防止离职维护人员仍持有设备密钥。大规模部署时，需规划固件与密钥的批量更新窗口，避免同时唤醒导致空中拥塞。
蜂窝网关与边缘计算
网关作为 Mesh 与云之间的桥梁，应实现本地规则引擎：在蜂窝中断时仍能执行场景联动与告警。出口侧需协议转换、压缩与批量上报，减轻 MQTT 或 HTTP 连接数压力。对跨省项目，可就近接入边缘节点降低时延。与模组侧协同，要监控网关 CPU、内存与 Mesh 侧丢包率，提前扩容或调整中继节点。
工程实践补充
从「蓝牙 Mesh」出发，现场常见问题往往集中在「指标在实验室达标、外场复现困难」。除射频与协议外，还应排查电源地弹、连接器接触与固件竞态。蜂窝侧建议采集 RSRP/SINR、小区重选与 PDP 重建记录；应用侧对重试、幂等与队列持久化要有明确策略。涉及数据安全与合规时，把采集范围、存储位置、保留期限与第三方共享写进隐私与合同附件，避免上线后补洞成本过高。
中继太密时泛洪会堵住控制
蓝牙Mesh的技术含义，是在低功耗蓝牙广播之上做多对多转发：节点既是设备也是中继，灯具、传感器用发布和订阅交换状态，而不是每盏灯都和网关保持一条连接。使用条件是中继数量够把区域盖住，但又没有密到让同一条消息被反复洪泛。跳数和生存时间要按场地直径来设。照明可以接受稍慢的到达，门锁和告警不行，后者应走带确认的消息，并规定超时后的本地动作。
配网把设备密钥和应用密钥分开。只把应用密钥写进网关、不规划撤销，离职维护人员仍能控制设备。大规模更换固件时，若让所有节点同时醒来请求升级，空中会被自己的流量占满。应分批、限速，并保留未升级节点仍能工作的模型。
密钥撤销之后的离线节点
蜂窝网关是Mesh和云之间的翻译器，不是Mesh时序的延伸。出口带宽远大于网内带宽，云端一次群控会在网关里堆成队列。网关应缓存离线命令，并在蜂窝中断时继续执行已经下发的本地场景。把每一盏灯的状态都实时推到云上，只会制造拥塞，却不能让现场更快。
容易错的是用手机配网的习惯管理无人值守网络：没有审计、没有备份、密钥只存在一台调试电脑里。网关掉电后，若密钥和场景没有落在可恢复的存储，整网需要重新配。上行解析和连接见蜂窝DNS；需要在本地先做联动、再择要上云时，把规则放在边缘节点，不要等云端往返。
电池节点不要被配成中继
电池传感器一旦承担转发，就会替别人转发广播，电量按天而不是按年下降。中继应放在常供电的灯具或网关上，并限制转发次数。房间之间的墙若把网络切成两半，应在门口加一颗常供电中继，而不是把生存时间调到最大，让消息在半边网络里打转。配网记录里要能看出谁是中继，否则维护时无法解释为什么只有某一批节点掉电特别快。