接口签名错误主因是校验细节不一致，Signature Validator 通过重算比对验证，需严格统一参数、顺序、编码、密钥及时间窗口；关键头部 appid、timestamp、nonce、signature 必须齐全合规；重算须按字典序拼接参数+appSecret 并 UTF-8 编码后哈希；常见坑包括 urlencode 差异、时间单位错配、JSON 序列化顺序不一致、header 取值大小写或空格问题、appSecret 含不可见字符；调试应打印完整参与计算的字符串进行手动验证。
接口签名错误，通常不是算法本身出问题，而是校验环节某个细节没对上。Signature Validator 的核心逻辑是“重算比对”，但重算的前提必须和客户端完全一致——参数、顺序、编码、密钥、时间窗口，缺一不可。
关键参数必须齐全且格式正确
服务端收到请求后，首先要提取并检查以下四个头部字段：
- appid：必须存在，且需在系统中预注册，对应有效的 appSecret
- timestamp：必须是标准 Unix 时间戳（毫秒或秒），服务端要校验是否在允许窗口内（如 ±10 分钟）
- nonce：长度不少于 10 位的随机字符串，不能重复；办理类接口还需查库确认未在有效期内使用过
- signature：不能为空，且需为合法 hex 字符串（如 32 位 MD5 或 64 位 SHA256）
签名重算过程必须严格对齐
Validator 不是简单拼接再哈希，而要还原客户端生成 signature 的完整路径：
- 将 appid、timestamp、nonce 按字典序升序排列（例如 appid → nonce → timestamp），拼成键值对字符串：
appid=xxx&nonce=yyy×tamp=zzz - 若业务参数在 body（如 JSON），需先解析并按 key 字典序序列化为
a=1&b=2&c={"x":"y"}形式，再追加到上一步结果后 - 末尾拼接 appSecret（注意：不是 appKey，也不是明文密码，是分配给该 appid 的密钥）
- 统一用 UTF-8 编码后，执行指定算法（MD5 / HMAC-SHA256 等），输出小写 hex 格式结果
常见导致 validator 失败的隐藏坑
这些点不报错，但会让重算结果和客户端签名永远不一致：
- 客户端用了
http_build_query()（自动 urlencode），服务端却直接拼接原始值 - timestamp 客户端传的是秒级，服务端按毫秒解析，或反之
- body 是 JSON，但服务端用 ObjectMapper 反序列化后再 map 排序时，丢失了原始字段顺序或空值处理不一致
- header 中取值时未 trim 空格，或大小写混淆（如传
AppId，代码却取appid） - appSecret 在配置文件里带了不可见字符（BOM、换行、全角空格）
调试建议：加一层可复现的日志
在 validator 执行重算前，把实际参与计算的字符串原样打出来（脱敏后），例如：
[DEBUG] signing string: appid=abc123&nonce=xyz789×tamp=1723875000&key=xxxxxx再拿这段字符串手动用相同算法跑一遍，看结果是否匹配。如果手动结果对了但代码不对，说明代码里有隐式转换或截断逻辑。
