一家做生鲜电商的客户下午突发全线停摆：第三方物流价格接口升级出错，而他们的下单流程同步等这个接口返回，接口挂，下单跟着挂，一小时几百单进不来。修复当然靠对方，但把自家生死绑在别人家的接口上，是后端系统开发里最常见的韧性缺失。
第一课：设超时
检查所有对外部接口的调用，没有设超时的先补上，这是零成本的保命符。默认不设超时，对方一卡，你的请求线程就跟着吊死，几十个并发一来，自己的线程池先耗尽，明明是别人家的故障，倒下的却是你的系统。超时给两秒是常见选择，宁可拿不到数据走降级，也不能干等。
第二课：重试要有节奏
- 失败后立即重试往往撞在对方故障的枪口上，间隔递增才合理：两秒、八秒、三十秒，最多三次；
- 重试只适合幂等的操作，查询类随便重试，下单类要先想清楚会不会造成重复单；
- 重试仍失败的，落进待处理队列定时再试，或者转人工，别让数据悄悄消失。
第三课才是真正的韧性来源：降级。核心问题是先想清楚答案——这个接口挂了，业务怎么办？物流价拿不到，就用预设的默认运费，单照收，事后补差；短信通道故障，通知先进队列，通道恢复后补发；汇率接口挂了，用昨天缓存的汇率。降级不是放弃功能，是给业务留一条走得通的路，哪怕走得慢一点。
第四课是拆分关键路径。下单流程里只有扣库存和支付是必须成功的，物流报价、积分预增、消息通知都该挪出同步链路。关键路径越短，系统被外部拖死的面积越小。那家生鲜客户改造后，物流接口再挂，下单照常，只是运费暂时用默认值，客服话术都准备好了。
第五课是关键通道配备份：短信服务商签两家，主通道故障自动切备胎；支付渠道同理。切换要自动，靠人半夜爬起来改配置的备份，等于没有。
把预案变成文档
每个第三方接口整理一张卡片：用途、超时设置、重试策略、降级方案、责任人。日常看不出价值，故障当晚这张卡片就是指挥图。没有预案的团队，故障时第一小时都在互相问现在该怎么办。
两条建议：验收系统时逐个问第三方接口挂了怎么办，答不出降级方案的，让开发方补上再上线；自己的系统也该做一次外部依赖盘点，把同步等待的调用拆出来。比格网络做系统设计时，外部依赖的降级预案是方案评审的固定议题，韧性不是出了事故才补的课，是后端系统开发设计图上就画好的一道墙。
