单纯加时间戳不能防重放，因攻击者可篡改时间戳重发；需配合nonce实现唯一性校验，服务端须存储并检查nonce是否已使用，且与时间戳窗口一致。
为什么单纯加时间戳不能防重放
时间戳只是校验请求是否“过期”，但攻击者截获一次合法请求后，把里面的时间戳改成当前时间再重发，照样能过校验。关键缺了唯一性约束——同一时间戳下，请求必须只能被接受一次。Nonce（一次性随机数）就是干这个的：服务端收到带 nonce 的请求，先查缓存/数据库有没有见过它，有就直接拒绝。
如何生成和验证 nonce 才不踩坑
常见错误是用 Guid.NewGuid().ToString() 当 nonce，看似唯一，但没做存储校验或过期清理，等于白搭。正确做法要闭环：
-
nonce建议用加密安全随机数，比如Convert.ToBase64String(RandomNumberGenerator.GetBytes(16))，避免可预测性 - 服务端必须持久化记录已用
nonce，推荐 Redis（带 TTL）或内存缓存（如MemoryCache配SlidingExpiration） - 过期时间建议设为略大于最大允许时钟偏差（比如 5 分钟），且必须和时间戳窗口一致，否则会出现“
nonce还活着但时间戳已失效”的逻辑断层 - 不要在日志里明文打印
nonce或签名原文，防止密钥泄露链路被绕过
HMACSHA256 签名时参数顺序和编码细节决定成败
签名算错，90% 出在拼接字符串的格式上。C# 默认 Encoding.UTF8，但前端 JS 可能用 encodeURI 或 encodeURIComponent，导致同样参数签名不一致。必须统一约定：
- 签名原文按固定字段顺序拼接：
timestamp+nonce+method+path+bodyHash（如有）——注意全部小写、无空格、无换行 -
bodyHash推荐用SHA256(bodyBytes)的十六进制小写字符串（非 Base64），避免 body 编码差异影响 - 密钥必须用
Encoding.UTF8.GetBytes("your-secret-key")，别用ASCIIEncoding，否则中文或特殊字符会截断 - 签名结果转成十六进制小写字符串（
BitConverter.ToString(bytes).Replace("-", "").ToLower()），别用 Base64，兼容性差且易出错
ASP.NET Core 中间件里怎么安全拦截并校验
别在 Controller 里做签名校验——body 可能已被读取一次，再次读取会失败。必须用中间件提前捕获原始流：
- 调用
context.Request.EnableBuffering()允许多次读取 body - 用
context.Request.Headers["X-Signature"]、["X-Timestamp"]、["X-Nonce"]提取签名三要素 - 校验时间戳是否在窗口内（比如
Math.Abs(now - timestamp) > 300秒就拒） - 查
nonce是否已存在；若通过，立刻存入缓存并设 TTL，防止并发重复提交漏判 - 重新读取
Request.Body计算bodyHash，再拼接签名原文、用密钥计算 HMAC，比对X-Signature - 校验失败统一返回
Status401Unauthorized，**不要暴露具体失败原因**（比如不说“nonce 已使用”，只说“签名无效”）
最常被忽略的是 body 流的 rewind 和 encoding 一致性：本地测试用 Postman 没问题，上线后前端用 axios 发送 JSON，body 自动带 BOM 或换行，签名就对不上。建议在中间件开头加一行日志输出 bodyHash 的实际值，出问题时能快速定位是前端传错了，还是服务端读取方式不对。
