接口签名校验需统一算法与参数处理流程，含时间戳、nonce防重放，服务端用Filter/Interceptor校验，参数排序拼接后加secretKey哈希，安全比对签名并防范时序攻击。
接口签名校验是保障API通信安全的核心机制，Java中通常通过约定签名算法（如HMAC-SHA256）、时间戳、随机数（nonce）和参数排序等方式，防止请求被篡改或重放。关键不在“写个签名方法”，而在于服务端与客户端严格一致的生成逻辑、合理的时效控制、以及对非法请求的快速拦截。
签名生成规则要统一且可复现
客户端和服务端必须使用完全相同的签名算法和参数处理流程。常见做法是：
- 将所有请求参数（除red">sign字段外）按字典序升序排列
- 拼接为key1=value1&key2=value2格式（不带空格，value需URL编码）
- 在字符串末尾追加预共享密钥（secretKey），如sortedString + secretKey
- 用指定哈希算法（如HmacSHA256）计算摘要，并转为十六进制小写字符串
注意：secretKey绝不暴露在前端或日志中；建议每个应用分配独立密钥，并支持动态轮换。
必须校验时间戳与防重放
签名本身不防重放攻击，需配合时间窗口机制：
立即学习“Java免费学习笔记（深入）”；
- 请求中携带timestamp（毫秒级时间戳），服务端拒绝超过5分钟（如System.currentTimeMillis() - timestamp > 300000）的请求
- 引入nonce（一次性的随机字符串），服务端缓存最近5分钟内已使用的nonce（可用Redis Set实现），重复则拒绝
- 时间戳与nonce必须参与签名计算，否则校验无意义
Spring Boot中典型拦截实现
推荐在全局过滤器（Filter）或拦截器（HandlerInterceptor）中完成签名校验，避免侵入业务逻辑：
- 提取timestamp、nonce、sign三个必要字段，任一缺失直接返回401
- 验证时间戳有效性；查重nonce并写入缓存（注意设置过期时间）
- 从HttpServletRequest中获取全部参数，排除sign后排序拼接，生成服务端签名
- 使用MessageDigest.isEqual()安全比对签名（防时序攻击），不直接用equals()
常见陷阱与加固建议
实际落地中容易忽略的细节：
- GET请求参数在Query String里，POST表单在body里，JSON请求需先解析body再取字段——统一用getParameterMap()不够，应封装通用参数提取器
- 中文、特殊字符未正确URL解码会导致签名不一致，务必在拼接前对value调用URLDecoder.decode(value, "UTF-8")
- 不要把签名逻辑写死在Controller里；抽取为独立Service，便于单元测试和算法替换
- 生产环境开启签名日志（仅记录URI、timestamp、nonce、sign前缀），便于问题追踪但不泄露密钥
