kpay-crm-web 架构学习复盘：安全签名机制

今天学习了 kpay-crm-web 项目的安全签名机制（src/utils/requestSignature.ts），记录三处理解偏差，供后续复习。

偏差一：把签名机制当成登录凭证

错误理解：signature、nonceStr、timestamp 这些字段是用来做登录凭证的。

正确理解：签名和 token 解决的是两个不同的问题：

• Authorization: Bearer token → 证明你是谁（身份认证）
• signature + nonceStr + timestamp → 证明这条请求没有被重放和篡改（请求完整性）

两者是叠加关系，不是替代关系。签名防的是重放攻击：黑客截获一条合法请求后原封不动重发，token 校验无法识别，但签名中的组合可以拦截：

• timestamp：时间窗口，超过 N 分钟后端直接拒绝
• nonceStr：32 位随机串，每次请求重新生成，后端记录已用过的，第二次出现直接拒绝

偏差二：把 HmacSHA256 理解为加密算法

错误理解：后端收到 signature 后用 secret 进行解密，还原出原始数据。

正确理解：HmacSHA256 是哈希算法，不是加密算法，不存在解密过程。

后端的处理方式是：用自己存储的 secret，按同样规则重新算一遍 HmacSHA256，然后把结果和请求中的 signature 对比，一致则合法。

偏差三：accessToken 不参与签名的原因理解不完整

错误理解：因为登录时还没有 token，所以不能参与拼接。

正确理解：这个原因是对的，但只说了一半。完整原因有两个：

1. 登录等无 token 场景：部分接口调用时尚未登录，accessToken 为空，若参与签名则无法计算。

2. token 刷新后不需要重算签名（更关键）：token 过期是在请求发出后后端返回 401 才知道的。若 token 参与签名，刷新后必须重新计算签名再重发；而 token 不参与签名，刷新后只需把新 token 换进 header，签名不变，直接重发即可。

根因总结

这三处偏差有一个共同根因：对"请求安全"这个领域之前没有系统接触过，遇到陌生概念时，习惯用已知的"身份认证"框架去套，导致把不同职责的东西混为一谈。