一句话结论：两者用的是同一套密钥协商算法，差别只在"要不要人确认那个 6 位数字"------Numeric Comparison 弹数字让用户比对确认，Just Works 直接跳过确认。因此前者能防中间人攻击（MITM），后者不能。
为什么会有这两种
BLE 配对时会先交换双方的 IO Capability（有没有屏幕、有没有键盘），然后查表决定用哪种配对方法：
| 设备 A / 设备 B | 结果 |
|---|---|
| 双方都有 Display + YesNo（如手机↔手机、手机↔带屏车机） | Numeric Comparison |
| 任意一方是 NoInputNoOutput（如手环、耳机、无屏传感器） | Just Works |
| 一方 Display、一方 Keyboard | Passkey Entry |
| 带外通道（NFC 碰一下） | OOB |
所以本质上：Just Works 就是 Numeric Comparison 在"有一方没有交互能力"时的退化版本。协议层面它们的确认阶段是同一个（LE Secure Connections 下都走 Elliptic Curve Diffie-Hellman，P-256 曲线），代码路径都类似，只是 Just Works 把用户确认那一步自动置为"通过"。
关键差异
| 维度 | Numeric Comparison | Just Works |
|---|---|---|
| 用户交互 | 双方屏幕各显示一个 6 位数字，用户按"配对/取消" | 无（很多系统连弹窗都不出，或只出"是否允许配对"） |
| 协议确认阶段 | Confirm 阶段需要人参与 | 自动确认 |
| MITM 防护 | 有 | 无 ⚠️ |
| 典型设备 | 手机↔手机、手机↔车机、手机↔带屏智能设备 | 耳机、手环、体重秤、蓝牙 Beacon、传感器 |
| 用户体验 | 多一步，但安全 | 无感配对，顺滑 |
为什么 Just Works 防不了中间人
Numeric Comparison 的安全性来自：攻击者要中间人劫持，必须分别和两台设备各建一条加密链路，两条链路上算出来的 6 位数字几乎必然不同，用户一比对就能发现。这一步"人眼比对"就是防护本身。
Just Works 没有这个人眼环节，攻击者可以静默地站在中间完成配对，双方毫无感知。所以：
- 传输本身仍是加密的（不是明文），能防"路人被动嗅探"
- 但防不了"主动的中间人"
实践建议
- 敏感场景别依赖 Just Works 的配对做认证。支付、门锁、医疗数据、车钥匙这类，要么用 Numeric Comparison / Passkey / OOB，要么在应用层自己再加一层鉴权（比如设备预置证书、应用层 challenge-response），不要认为"配对成功 = 对端可信"。
- Just Works 也不是随便就能降级攻击------但如果一方谎报自己 NoInputNoOutput，就会把 Numeric Comparison 降级成 Just Works。这是真实存在的降级风险，所以 IO Capability 声明要和硬件实际能力一致，且要评估对方谎报的影响。
- LE Secure Connections 优于 Legacy Pairing。Legacy Pairing 下的 Just Works 连被动嗅探都防不住（密钥协商用的是可暴破的 TK），且长期密钥可被事后解密。尽量在配置里强制 SC（Secure Connections），关掉 Legacy。
- 绑定的持久性：两种方法都会生成 LTK 并可 Bonding 保存，重连不用重新配对。但 Just Works 的绑定关系一旦建立，攻击者若已冒充成功，后续重连也会一直信任他------这也是它风险被低估的地方。