先保存错误码和请求时间，再按下面顺序排查。不要把完整请求头发给别人：其中包含 Key、签名与 Passphrase。订单请求出现超时时，先按客户订单 ID 查单，再决定是否重试。
按错误码找到第一步
| 错误 | 先检查 | 怎么确认修好了 |
|---|---|---|
| 50101，环境不匹配 | Demo Key 与 x-simulated-trading: 1 是否配套 | 模拟余额查询成功 |
| 50102，时间戳过期 | 系统 UTC 时间、NTP 同步、请求排队时间 | 时间同步后重新生成时间戳和签名 |
| 50113，签名无效 | Secret、方法、完整路径、实际发送的 body | 同一字节串计算并发送，公开请求先可达 |
不要把 50101 修成“删除模拟请求头试试看”：这样容易把环境混乱隐藏起来。先明确自己只需要模拟盘还是实盘，再使用对应的一组 Key。
50102：本地时间正确，为什么还会过期？
显示的时区正确不代表系统时钟准确。对比 /api/v5/public/time 的服务器时间，并留意网络往返耗时。不要把刚启动程序时的时间戳缓存下来反复用；每次请求临近发出时重新生成。换时间戳之后，也必须重新签名。
50113：签的内容必须与发出的完全一致
REST 签名的输入是时间戳、大写 HTTP 方法、请求路径与请求体的拼接，使用 Secret 做 HMAC-SHA256，然后 Base64 编码。GET 的查询参数属于路径；没有请求体时不要追加字符串 null。
GET 路径示例：/api/v5/account/balance?ccy=USDT
POST 路径示例：/api/v5/trade/order最常见的程序问题是：先对一份 JSON 签名，发送时又让库重新序列化。空格、字段顺序或数字字符串改变，都可能让字节不同。把 JSON 只序列化一次，签名与发送共用同一份字符串。
返回 code=0，为什么下单仍然失败？
还要检查订单结果里的 sCode 和 sMsg，以及后续订单状态。接单确认、挂单、部分成交、完全成交、撤单是不同阶段。修好认证之后的数量错误，转到合约张数计算器；完整模拟流程见Demo API 教程。
给开发者或客服什么信息最有用？
提供请求方法、路径、UTC 时间、错误码、SDK 版本和脱敏后的数量字段即可。删掉 Secret、Passphrase、Key、签名和所有账户余额。不要上传整份 .env 或完整调试日志。
