接入方遇到 40001 按文档当参数缺失处理，改了两天参数，实际原因是签名不匹配。乍看像缓存或者权限的锅，追下去往往不是。
curl -s -X POST https://api.example.com/v1/order -d '{}' | python -m json.tool
追下去是这么回事：错误码表里 40001 写的是参数错误，签名失败也复用了这个码，响应体里没有子码。接入方只能按最可能的解释去试。
「错误码含义不清」相关的日志我一般连着看前后五分钟，单看一条报错经常判断不出是哪一步失败。一次只改一处，改完立刻验证，几个改动叠在一起，出问题就说不清是谁导致的。
先做最小复现，能稳定跑出来的问题，排查成本会低一个数量级。别只看报错的最后一行，往上看几行，真正的起因通常在上面。
同类问题如果隔一段时间又出现，多半是某个定时任务或重启流程把改动冲掉了。
具体做法是，给签名失败单独分配错误码；响应体带 detail 说明具体哪一步失败；更新错误码文档并同步给接入方；旧码保留一个版本做兼容。
验收就看一点，错误签名请求返回新的签名错误码 接入方能直接定位。