这其实是厂商针对处理敏感数据的BLE设备做的专属配对权限锁设计，我来拆解一下背后的逻辑和你遇到的问题本质：

• 厂商固件的额外验证逻辑：这类设备的固件里并没有单纯依赖蓝牙标准的PIN码配对流程，而是加入了「发起方身份校验」的额外环节。系统蓝牙探索器发起的配对请求，只会走标准BLE配对步骤，但设备会检查请求的来源——只有厂商APP发起的请求，才会触发后续的配对确认；系统蓝牙的请求会被直接判定为非授权请求，哪怕你输入了正确的PIN，也会返回配对失败。
• 广播中的密钥并非有效配对凭证：你从设备广播中获取的“配对密钥”，大概率只是设备广播的临时公钥、混淆后的密钥片段，或者是用于APP预验证的密钥，而非系统配对所需的有效PIN。即使巧合是正确的PIN，因为缺少APP层面的前置验证步骤，设备依然会拒绝配对。
• 敏感数据的安全防护需求：因为设备处理敏感数据，厂商这么做是为了彻底封锁非授权访问渠道——标准蓝牙配对的安全性无法满足这类设备的需求，通过绑定厂商APP，可以在配对流程中加入APP签名校验、自定义加密验证等多重防护，避免敏感数据被系统蓝牙或第三方APP获取。

验证思路（供参考） #

如果你想确认这个逻辑，可以用nRF Connect这类BLE调试工具，分别抓包：

1. 厂商APP与设备的完整配对通信流程
2. 系统蓝牙发起配对时的通信包
   对比后会发现，厂商APP在配对前后多了几个自定义的GATT读写操作，这就是设备要求的前置验证步骤，系统蓝牙完全跳过了这一步，自然无法完成配对。

内容的提问来源于stack exchange，提问作者FishingIsLife