1. 先从“为什么需要一个Provisioner”说起
接触过BLE Mesh的人都知道，Mesh网络和咱们平时用的BLE 1对1连接完全是两回事。传统BLE是“一个主机对一个从机”，连接是点对点的；而BLE Mesh是广播式的，设备之间可以互相中继转发，形成一张“员额互联”的网络。但有一个问题容易被新手忽略——网络不是凭空出现的，节点之间怎么互认？谁来决定谁可以入网？入网之后用什么密钥通信？地址怎么分配？这些事不会自己发生，总得有个角色负责统筹，这就是Provisioner（配置者）。
我最早踩过的一个坑，就是以为BLE Mesh的核心是“把设备加进网络”这一步，结果反复折腾设备入网时才发现，真正麻烦的是Provisioner这一侧的设计。配网流程看起来只是“手机扫一扫，设备入网”，实际背后要走一整套密钥协商、身份校验、地址分配、模型绑定流程。如果Provisioner设计得不好，轻则配网速度慢、成功率低，重则整个网络的安全体系都会出问题。
这篇文章不聊太高深的东西，就把Provisioner这件事讲透。我会从角色定位、配网流程、关键数据结构、实操注意事项到故障排查，完整走一遍。适合正在做BLE Mesh开发、或者刚接触Mesh想快速上手的读者。不管你是做智能家居网关、照明控制，还是做传感器网络，理解了Provisioner这条主线，后面读协议栈源码和调试问题都会轻松很多。
2. Provisioner到底是什么角色
2.1 一个容易被忽略的“网络管理员”
在BLE Mesh里，设备分两大类：一个是已经入网的节点（Node），另一个是还没入网的设备（Unprovisioned Device）。Provisioner就是那个负责把Unprovisioned Device变成正式节点的角色。打个比方，Mesh网络像一个大楼，Provisioner就是物业管理员，新住户搬进来要登记、领门禁卡、分配房间号，这个登记发卡的过程就是Provisioning。
但Provisioner不只是“发钥匙”这么简单。它还是整个网络的管理者：
- 负责生成并分发网络密钥（Network Key），让设备之间能安全通信；
- 负责给每个节点分配唯一的单播地址，保证网络中数据包能被正确路由到目标设备；
- 负责管理应用密钥（App Key），控制上层业务数据（比如灯的亮度、开关状态）只被授权设备访问；
- 在节点需要被移除或密钥需要更新时，Provisioner也需要执行相应的管理操作。
换句话说，Provisioner的权力很大。它不仅是一切设备入网的入口，也从一开始就掌握了整个网络的密钥体系。所以现实项目里，Provisioner通常不会只是一个临时APP，而会落在网关、手机、或者专用的调试工具上，扮演长期存在的“网络管理中心”角色。
2.2 一个Provisioner能管多少个设备
这个问题没有固定答案，取决于你的设备资源。理论上一个Provisioner可以管理几万个节点，但实际项目里要考虑内存、存储和交互效率。我之前做某照明项目时，一个小型网关当Provisioner，管理了大概50个灯节点，运行得稳不错；但如果用手机当Provisioner，配完网之后手机APP退后台、被系统杀掉，这个Provisioner就“暂时离线”了，好在Mesh网络的通信并不依赖Provisioner持续在线。
这里需要澄清一个常见误解：Provisioner做完配网工作后，网络是去中心化运行的，节点之间靠消息互相通信，不需要每次都经过Provisioner。Provisioner只是在配网、密钥更新、删除节点等管理操作时才需要介入。所以即便配网工具只是一个一次性APP，配完网就卸载掉，Mesh网络也能正常工作。这也是BLE Mesh相对传统蓝牙连接的一个核心优势。
2.3 Provisioner的载体选择
做项目时选什么设备当Provisioner，直接影响开发复杂度和用户体验。
| 载体类型 | 优势 | 劣势 | 典型场景 |
|---|---|---|---|
| 手机APP | 开发快、交互灵活、适合调试 | 后台易被杀、不适合长期在线管理 | 开发调试、小规模配网 |
| 网关设备 | 7x24在线、可长期做网络管理 | 成本高、开发周期长 | 智能家居、商业照明 |
| 专用配网工具 | 便携、针对性强 | 功能单一、不适合大规模管理 | 现场施工、工程调试 |
从开发角度说，刚开始学习用手机APP做Provisioner最方便，因为不需要额外硬件，用现成的蓝牙开发工具就能发起配网。但真正做产品，建议一开始就把网关方案考虑进去，否则后期从“手机配网”切换到“网关配网”，整个协议栈和业务逻辑都要调整，返工量很大。
3. Provisioning配网流程深度拆解
3.1 配网前设备如何被发现
Unprovisioned Device在等待配网时，会持续发送一种叫“Unprovisioned Device Beacon”的广播包。这个广播包里面不包含设备名，而是包含设备UUID和一个标志位，表示“我有待配网”。手机或网关里的Provisioner扫到这个广播包以后，就能据此知道附近有设备需要入网，进而在UI上展示出来，让用户决定是否配网。
这里有个实操细节：Unprovisioned Device Beacon使用的是不可连接、不可扫描的广播类型，它本身不携带服务UUID等应用层信息，也不能通过常规的“扫描服务”方式去过滤。调试时如果想确认一个设备是不是在待配网状态，可以用抓包工具直接看广播包类型，也可以看设备的Mesh协议栈日志。我在某项目里就遇到过设备明明已经烧录了固件，但就是扫不到待配网广播，最后发现是设备上电后进错了模式，压根没有进入Provisioning状态。
3.2 从广播到入网的五步协商
Provisioning并不是“发个密钥过去就完事”那么简单。完整的配置流程是由多个PDU（协议数据单元）交互完成的，协议栈内部把它们封装成了几个阶段。我习惯把它拆成五步来理解：
- Beaconing：未配网设备广播自身存在，等待Provisioner发现。
- Invitation：Provisioner向设备发起配网邀请，设备回应自己的能力信息（支持多少元素、支持哪些认证方式等）。
- Exchange Public Keys：双方交换公钥，建立一条加密通道。默认使用ECDH密钥协商。
- Authentication：通过OOB（Out-of-Band）方式校验设备身份，防止中间人攻击。
- Distribution of Provisioning Data：Provisioner把网络密钥、单播地址、IV Index等参数分发给新设备，设备正式入网。
我对其中几个容易出问题的点特别有感触：
- Invitation阶段返回的能力信息，决定了后续配网过程的很多选择。如果设备说自己不支持某种OOB方式，而你偏要用这种方式，配网必然失败。所以Provisioner在邀请阶段就要根据设备能力，动态决定接下来的认证方案。
- 公钥交换阶段支持“设备预置公钥”和“临时生成公钥”两种模式。预置公钥适合工厂批量生产时把公钥烧进去，配网更安全，但实现复杂；临时生成公钥开发最简单，但如果中间有人恶意监听和篡改，存在被攻击的风险。家庭和商用环境的威胁模型不同，选型时要想清楚。
- Authentication阶段是安全的关键。OOB认证一般分三种：Static OOB（静态PIN码，像“123456”）、Output OOB（设备某种方式显示一个随机数，人工确认）、Input OOB（用户在设备上输入随机数）。产品设计上，如果你只有一个普通传感器，没有显示屏也没有按钮，那我建议用Static OOB甚至No OOB，不要为了“看起来安全”硬上Input OOB，反而没法操作。
3.3 配网数据里到底发了什么
完成配网数据分发后，新节点会得到一串关键参数，最核心的有：
- Network Key：网络层加密密钥，所有合法节点共享，用于消息的加密、认证和中继。一旦节点丢失该密钥，就其实被踢出了网络。
- 单播地址：节点在网内唯一的身份标识。协议栈会基于这个地址做出消息路由和模型订阅分发。
- IV Index：网络IV更新的索引值，参与加密和解密的随机因子。在网络安全更新时会变化，节点必须同步它才能继续通信。
- TTL、Network Flags等杂项参数，用于控制消息的最大跳数、消息分段策略等。
配网完成后，节点还会把Composition Data发给Provisioner，这一步通常在配网后的“Composition Data Get/Status”阶段完成，Provisioner据此知道这个节点上挂了多少个Element、每个Element支持哪些模型。别小看这一步，后面你绑定App Key、控制具体功能，都要依赖这份“设备能力清单”。
4. 关键数据结构与地址分配规则
4.1 Composition Data是什么
Composition Data可以理解成设备的“配置清单”，它描述了设备在Mesh网络里的基本组成结构。我举个例子：一个灯柱上装了三个灯具，每个灯具都能独立控制，那这个设备可能就有三个Element。每个Element都有自己的地址和模型集。
Composition Data的Page 0是最常用的那一页，里面包含：
- 设备所属公司ID（CID）；
- 产品ID（PID）、版本ID（VID）；
- 设备支持的元素数量；
- 每个元素上的模型列表，区分SIG模型和Vendor模型。
配网完成后，Provisioner会主动读取这个数据。如果设备端没有正确上报Composition Data，或者上报的数据和实际模型不一致，后面App Key绑定和控制就会乱套。我遇到过设备明明有两个Element，结果上报的时候只写了一个，调试了好久才发现，明明只是数据结构没写对。
4.2 单播地址怎么分配合理
单播地址是Mesh网络节点身份的基石。分配规则本身不复杂，但实际项目中特别容易踩坑。
Mesh协议规定，单播地址一共16位，范围从0x0001到0x7FFF都是可分配的节点单播地址。每个Element占一个地址，所以设备A有一个Element，就分配一个地址；设备B有5个Element，就要分配连续的5个地址。
那意味着，你设计Provisioner的地址分配算法时，不能简单地“每次分配一个地址就加一”，而是要根据设备的Element数量一次性划出一块地址段。我见过最典型的错误是：配网工具只记录了“下一个可用地址”，没有考虑设备Element数量，导致分配地址出现重叠，网络上两个节点用同一个地址，消息就乱了。
一种稳妥的做法是：
- Provisioner内部维护一个allocated地址位图或区间表；
- 每入网一个设备，根据该设备上报的Element数量，连续分配相应数量的地址；
- 从0x0001开始递增分配，直到0x7FFF为止（实际上不建议用满，留一些余量给后续新增节点）；
- 组地址则从0xC000开始，不属于单播地址，用途不同。
还要考虑一个细节：如果某个设备配网成功后又从网络中删除，它的地址理论上可以被回收再利用。可如果你在开发初期图省事不回收地址，长时间运行后，地址池会慢慢变少。我做某项目时，就因为删除设备后没有释放地址，最后线上有几十个设备配不进去，排查下来才发现是地址空间“假耗尽”。
4.3 密钥体系不能只懂一种
BLE Mesh密钥体系至少分三层：
- Network Key（NetKey）：所有节点共享，保护网络层消息；
- Application Key（AppKey）：保护应用层业务数据，不同的业务可以绑定不同的AppKey；
- Device Key（DevKey）：只存在 Provisioner 和节点之间，配网后用来做节点与Provisioner之间的安全通信。
很多业务场景，一个AppKey就够用了。但如果你的产品同时跑“照明控制”和“能耗采集”两个业务，建议给它们分别用不同的AppKey，这样权限边界更清楚。一个用了AppKey1的灯控制消息，不会被当成能耗采集消息被另一个节点处理。即便是同一个节点上的不同Element，也可以绑定不同的AppKey，实现更细粒度的控制。
有个实操经验：配网初期不要贪多，统一用一个AppKey把功能跑通，再去拆AppKey权限。一来省得调试时搞混，二来真正理解每个key的作用之后再细分会更清晰。
5. 实操：把Provisioner跑起来要解决哪些事
5.1 环境搭建与协议栈选择
做BLE Mesh开发，你可以选择从底层自己写，也可以选择用现成的协议栈。自己做的好处是理解深入，代价是周期长；用现成协议栈则更快，但有些东西会被封装起来，出问题如果不懂底层会难查。
我个人的建议是：刚开始接触Mesh时，用官方或者芯片厂商提供的SDK跑一个最简单Provisioner Demo。无论是手机端还是嵌入式端，先拿Demo确认基本流程通顺——能发现待配网设备、能成功配网、能下发数据——然后再逐步替换成自己的业务代码。这个“先跑通再替换”的思路可以少走很多弯路。
我最初做某跨平台系统时，一开始就急着改业务逻辑，结果配网都连不上，排查到最后居然是SDK初始化时参数配错了，白白浪费了两天时间。
5.2 配网时序问题要提起注意
BLE Mesh的配网流程有一个重要特点：配网过程中的PDU交互是半连接式的。Proxy协议模式下，Provisioner和待配网设备之间建立GATT连接，然后通过Mesh Proxy Service通信；PB-ADV模式下，则直接走蓝牙广播通道，不建立连接。
不管哪种模式，配网的PDU交互都要求严格的时序。设备在收到Invalid PDU或者长时间等不到预期PDU时，会主动终止配网。所以实现Provisioner时要考虑网络繁忙、蓝牙拥堵等情况，重传策略和超时时间要设计合理。
PB-ADV模式下有一个比较“隐晦”的坑：配网PDU承载在Adv数据里，如果信道环境不好，丢包率可能比较高。我在一个有很多WiFi设备的办公室环境里测试，PB-ADV配网偶尔会失败，而切到PB-GATT（代理模式）之后，成功率明显提升。原因是PB-ADV对信道占用更敏感，容易因为空中包太多导致互相干扰。如果你的产品需要现场施工配网，建议优先考虑PB-GATT方式，或者至少两种方式都实现，方便在恶劣环境下切换。
5.3 一个简单的Provisioning流程伪代码
这里给一个类似实际开发时的流程思路，不局限于具体SDK，方便理解：
1. 启动扫描，监听Unprovisioned Device Beacon； 2. 收到beacon，解析UUID和OOB信息； 3. 用户确认选择该设备； 4. 发起Provisioning Invite； 5. 收到设备Capabilities（元素数量、支持算法、OOB方式）； 6. 发起公钥交换（ECDH临时密钥对）； 7. 根据能力选择认证方式（No OOB / Static OOB / Output OOB / Input OOB）； 8. 完成认证确认； 9. 向设备分发Network Key、单播地址、IV Index等； 10. 收到Provisioning Complete； 11. 建立会话，读取Composition Data； 12. 分配AppKey并绑定到设备模型； 13. 节点入网完成，开始正常通信。第9步分发的单播地址要提前规划好，不要临时算。第11步读Composition Data很重要，别看它不起眼，后续模型绑定、发布订阅配置全靠它。
5.4 Provisioner自己的数据持久化
这个点太容易忽略了——Provisioner必须保存自己的状态，否则重启后一切归零。
包括但不限于：
- 已分配的地址池状态；
- 已配网节点的设备信息（UUID、单播地址、Element数量）；
- 所有NetKey、AppKey的索引和密钥值；
- IV Index当前值和更新状态；
- 节点的模型绑定情况、发布订阅配置等。
为什么这么重要？因为Mesh网络里的节点并不知道Provisioner会重启。如果Provisioner重启后忘了自己分配过哪些地址，下次配个新设备时分配了一个旧地址，那这个新设备和旧节点就地址冲突了。网络消息会乱传，而且这种问题在现场极难排查。
我自己的习惯是，Provisioner每次成功完成一个配置动作后，立即把状态写入Flash或数据库，不能等到配完一批再统一保存。某项目里供电不稳，有次配完第五个设备还没来得及保存，突然断电重启，结果有两个节点的地址有重叠，最后的解决办法是逐个重置重新配网，劳民伤财。
6. 常见问题与排查技巧实录
6.1 配网失败最常见的几类原因
我整理了一个问题速查表，是实战中遇到最多的情况：
| 现象 | 可能原因 | 排查方向 |
|---|---|---|
| 扫描不到待配网设备 | 设备没有进入Provisioning模式 | 确认设备广播状态、检查beacon上报 |
| 收到Invite但设备无响应 | PB-ADV丢包、距离太远 | 换PB-GATT、缩短距离 |
| 公钥交换失败 | ECC密钥对生成异常 | 查看算法支持、确认计算资源 |
| 认证阶段卡住 | OOB方式不匹配、用户没操作 | 检查设备能力上报、调整认证方式 |
| 配网数据分发失败 | 单播地址冲突、地址空间不足 | 检查地址池、回收删除节点地址 |
| 配网完成后通信异常 | AppKey绑定不对、模型没配对 | 读取Composition Data、核对Element模型 |
6.2 一次“配网成功但控制不了”的排查经历
之前在某模拟项目X里，设备配网成功了，节点也出现在网络里了，但发送控制消息就是没反应。排查日志时发现，消息已经按单播地址发出去，节点也收到了，但从节点上看消息被丢弃了。后来仔细核对，问题出在AppKey没有绑定到目标模型的Element上。
很多新手很容易忽略：节点入网只代表它进了网络层，但应用层的模型不一定已经绑定好了AppKey。你直接发AppKey加密的指令，节点根本不知道该用哪个模型处理。所以配网完成后，一定要做“AppKey Update”和“Model App Binding”两步操作，把AppKey绑定到具体的模型上，控制消息才能真正到达处理逻辑。
6.3 关于Provisioner安全性的实操心得
前面提到OOB认证方式，有人可能会觉得“No OOB在本地环境没关系”。但我想提醒一下，如果是商业场景，还是尽量选择Static OOB。哪怕只是一个固定PIN码，配上配网确认机制，也能拦掉大多数“非授权设备主动入网”的情况。
另一个安全细节是：配网完成后，Provisioner和节点之间的Config消息（比如更新密钥、删除节点）是通过Device Key加密的，而Device Key最好只在Provisioner和该设备之间共享，不要把它用于业务数据传输。
我踩过的一个坑是：做调试时把Device Key打印在日志里，结果忘了关掉调试打印，差点泄露出来。像这种安全参数，代码里一定要做访问控制，日志里也不要随意打全量。
6.4 批量配网时的效率优化
如果要给一整层楼的几十个灯同时配网，一个一个手动选设备、输PIN码，效率极低。现实项目中常见做法是：
- 使用“自动配网”模式：扫描到待配网设备后，自动按策略分配地址并完成配网，无需人工逐个确认；
- 对支持OOB的设备，可以先用NFC或二维码交换预置信息，减少人工输入；
- 配网命令支持并发或后台处理，避免UI阻塞。
但自动配网建议加一个“配网白名单”机制，比如通过设备UUID前缀过滤，只配属于本批次的产品，避免把隔壁邻居的同型号设备也“误配”进网。我在某商用照明项目里用UUID前缀过滤后，现场配网成功率基本做到了95%以上，剩下的基本都是物理距离太远或者电量不足。
7. 我最后想强调的几点体会
做了这么久Mesh相关开发，最大的感受是：BLE Mesh本身的协议规范并不算难，难的是把Provisioner这个角色在真实产品里做“稳”。很多问题不是配网协议不会走，而是工程化的细节没做到位——地址没有持久化、OOB方式没结合产品形态、Composition Data没核对、调试日志没保护安全参数。这些看似琐碎的点，恰恰决定了你的设备在现场能不能被快速、稳定、安全地配置起来。
如果你现在正准备做一个以Mesh为主的项目，我建议你先花一天时间把Provisioner的整个生命周期画出来：从第一次发现设备，到配网，到读Composition Data，到绑定AppKey，再到后续密钥轮换和节点删除，中间每一步都需要有明确的逻辑和容错方案。把这个流程捋顺了，再去看代码、调协议，你会发现自己对整个Mesh网络的理解会有一个质的提升。
最后再分享一个小技巧：调试Provisioner时，不要只依赖日志，尽量准备一个抓包工具或者Mesh调试APP，实时观察广播包和PDU交互过程。很多时候，日志停在“Waiting for Provisioning PDU”，但抓包能看到设备其实已经发了数据，只是你这边没收到或丢弃了。两种手段配合起来，排障效率会快非常多。
