本地签名工具校验通过，统一下单仍返回签名错误，应同时检查计算过程和凭据上下文。使用同一个错误 Key 生成并自校验，可能只能证明本地算法自洽，不能证明与支付服务端配置一致。

旧问题最终落在商户 API Key

2018 年的 V2 接入记录中，统一下单返回了以下形式的错误：

<xml>
    <return_code><![CDATA[FAIL]]></return_code>
    <return_msg><![CDATA[签名错误]]></return_msg>
</xml>

当时检查商户 Key 后恢复。这个经历说明凭据值得优先核对，但不代表所有 SIGNERROR 都只需要“换 Key”。

三种名称相近的配置要分开

配置作用
mch_id商户标识
AppSecret对应应用的接口凭据，用于其规定的授权流程
V2 API Key相应 V2 交易签名使用的商户密钥

商户号和 AppSecret 不能代替 V2 API Key。还应检查商户与 AppID 的对应关系，以及运行环境实际加载的配置。微信支付账户参数说明

对比的是实际发送内容

依次核对接口版本、签名类型、参与签名的字段和空值规则、字符编码、排序与大小写要求，再检查签名之后有没有修改参数。打印 Java 对象不等于看到最终 XML；日志脱敏也不能把排查必需的字段名和错误层级全部删掉。

官方 V2 错误表将 SIGNERROR 指向签名参数和方法检查，但外层 FAIL 与业务层 FAIL 仍需按实际响应区分。V2 统一下单

本地比对，不公开真实密钥

旧稿建议将 XML 和 Key 粘到在线工具，这种排查方式不应继续使用。真实密钥留在受控环境，使用可公开的合成测试数据检查算法，用脱敏字段及摘要定位请求差异。

不要在未确定原因时随意轮换线上密钥，也不要把 V2 的 XML 参数签名直接套到 V3。当前接入应选择对应协议及 SDK，旧案例仅解释这一类历史失败。