这类问题看似集中在一个 API 或参数上，真正决定可用性的却是状态归属、资源上限和失败后的恢复方式。 显示名称和随机设备 ID 都能被复制，只有私钥持有证明才能绑定一次握手。Web Crypto 生成不可导出私钥，公钥指纹经过用户确认后成为信任锚。
安全评审要从资产、攻击者能力和信任边界出发，并在每次状态转换重新授权。输入校验、速率限制和审计只能互补，任何一个都不能替代权限判断。
先把实现决策说清楚
先从数据和协议能保证的事实出发，再决定界面承诺。下面的规则都应有明确所有者、边界值和兼容策略，不能只存在于某次代码评审的口头共识里。
- 每次握手签名 nonce、双方身份和协议版本；轮换使用旧钥签新钥并设短重叠期，撤销列表带版本且优先于缓存信任。
- 把协议事实、用户意图和自动恢复分层；自动化只能恢复事实，不能推翻用户明确选择。
- 兼容性通过显式能力协商决定，旧客户端得到可解释的降级路径，而不是进入半可用状态。
“设备身份密钥：生成、保存、轮换与撤销的完整生命周期”的交付标准是正常路径可用、异常路径收敛、资源有界，并且用户能理解系统为何采用当前状态。 这样得到的不是演示代码，而是能解释、能降级、能回滚的生产能力。
最容易漏掉的失败路径
失败路径需要与成功路径共享同一套状态模型。只弹一个错误提示却不释放资源、不传播终态，下一次恢复就会继承脏状态。
- 只签自己的 nonce 会被中间人转接到另一个对端；清除浏览器数据后静默生成新身份又让用户误以为仍是原设备。
- 只修正界面状态而没有清理底层资源，下一次操作继承队列、锁或过期凭据并再次失败。
- 降级路径从未压测，主路径故障时所有流量同时进入更慢、更昂贵的后备方案。
上线前怎样验证
验证时同时观察两端状态、持久化记录和可观测指标。单看某个按钮或一次接口响应，无法证明整个闭环成立。
- 测试首次配对、密钥存储损坏、合法轮换、被盗撤销和旧页面持钥五条路径，确认双方显示与权限完全一致。
- 用乱序、重复和延迟消息驱动状态机，确认旧版本被丢弃且显式停止不会被自动恢复覆盖。
- 分别覆盖直连、中转、弱网、后台标签页和移动端，报告不能只给平均值或一次成功截图。
当实现能够安全降级、重复执行不产生额外副作用、故障指标早于投诉出现时，这项能力才算具备长期维护价值。