很多人以为对接电商平台接口，就是"调个 API 的事"。
真做过的人知道：写代码可能只占 20%，剩下 80% 都在处理那些不会写在文档里的事。
下面 7 件，按翻车概率排序。
1. Token 会过期，而且不会提前通知你
access_token 有有效期，refresh_token 也有。
最常见的翻车：主流程里做了续期，后台跑的定时任务还拿着旧 token，某天凌晨批量拉单全失败，你早上才知道。
动作：token 统一收口到一个地方管理，过期前定时刷新，所有调用都走同一层，不要各写各的。
2. 签名失败，90% 是时间不对
平台签名依赖时间戳。服务器时间漂移几十秒，签名就一直失败，而你一直在检查代码。
动作：服务器先对时（NTP）。签名失败时，第一个查的不是代码，是时间。
3. 限流是一堵看不见的墙
QPS 有上限，超了不一定报错，可能是静默降级，或者封你一段时间。
单机测试没问题，上线多台机器一叠加就超了——因为每台都在"自己限自己"，没人管全局。
动作：限流做在全局（比如 Redis 令牌桶），不要放在每台机器本地。
4. 平台改字段，不会发邮件通知你
某天某个字段突然返 null，或者类型从字符串变成数字。你的代码没改，但流程挂了。
动作：返回值做宽松解析 + 字段缺失告警。别让一个 null 把整条订单流程打挂。
5. 图片和详情页会失效
平台图片有防盗链和时效，你只存了 URL，过段时间客户看到的全是裂图。
动作：关键图片在入库时就转存到自己的存储。省的那点空间，赔的是客户体验。
6. 重试导致重复下单（这个最贵）
请求超时 ≠ 失败。可能已经成功了，只是响应丢了。
无脑重试 = 重复下单 = 重复付款。等客户来问"为什么扣了两次钱"，已经晚了。
动作：下单必须有幂等键（业务侧自己生成唯一订单号），并且有对账机制兜底。
7. 回调会丢，不能只依赖推送
状态回调会因为网络抖动、服务重启而丢。只靠回调，客户订单会永远停在"待发货"。
动作：回调 + 定时主动轮询，双保险。宁可多查，不要漏单。
一句话总结
这 7 件事，自己踩一遍大概要几个月，而且很多是钱已经付了才发现。
这就是为什么"现成接口"这件事有它存在的价值——不是省那点开发时间，是省掉这些没人告诉过你的坑。
