第三方API依赖识别：接口失效、限流、条款变更三类风险（依赖清单、失效模式、缓解）

第三方API依赖识别：接口失效、限流、条款变更三类风险（依赖清单、失效模式、缓解）本文档提供：表2依赖清单七字段表；表3接口失效扫描清单与式(1)外部暴露指数；表4限流扫描清单与式(2)配额余量消耗比；表5条款变更扫描清单与式(3)单方面变更敞口指数；表6三类风险联合判定表；表7停摆排查表；四条决策规则和一处矛盾；表8三套场景表；完整案例一个。2026-11-03表1目录与定位表这一节的标题读完你能拿到什么这一节在全文中的功能一、依赖清单先填七列：调用方、被调方、业务用途和断了谁受影响表2依赖清单七字段表建立可回答“谁依赖谁、断了影响什么”的清单二、接口失效：先分清“它挂了”和“只有你挂了”表3失效扫描清单和式(1)把失效从笼统的“不可用”拆到可定位的机制和暴露面三、限流：配额不是合同承诺时，余量就是不确定的表4限流扫描清单和式(2)识别配额类型、余量消耗速度和触发限流后的实际行为四、条款变更：通知期和变更范围是两条独立的防线表5条款扫描清单和式(3)判断合同是否真正约束了单方面变更，而不只是“有通知”五、三类风险联合判定：同一依赖可能同时命中三条表6联合判定表把三条扫描结果合成一张可升级的记录六、识别做了一轮就停在清单上，先查这五处表7停摆排查表定位清单有登记、没有评估的环节七、什么时候加备选、什么时候改合同：四条规则和一处矛盾四条决策规则和矛盾权衡规则处理工程缓解与合同缓解之间的资源取舍八、完整版、精简版、极简版按依赖关键度选表8三套场景表按依赖数量和关键程度选择执行范围按第一列在正文找对应那节，按第二列判断这节有没有你要的东西，按第三列判断这节是否对应你当前卡住的位置。调用方系统里登记了34个外部API，清单上每个接口都有“服务名称、提供方、负责人”，但上个月一家支付渠道把单笔限额从50万元降到5万元，另一个身份核验接口在促销日返回了429，两个问题都不是“接口挂了”，清单上没有任何一列能提前发出信号。一、依赖清单先填七列：调用方、被调方、业务用途和断了谁受影响API依赖清单最容易停在“接口目录”层面：有URL、有提供方、有版本号，但故障发生时回答不了“哪个业务流程会停、影响多少量、谁需要被通知”。可用的清单至少连接三样东西：调用方系统、被调方服务、业务用途和中断后果。API依赖治理的登记字段通常包括稳定的内部编号、服务名称、提供方、环境、版本、调用系统、业务用途、责任人、当前状态，对外部服务还应增加合同或服务周期、额度口径、SLA约定和技术支持渠道。表2依赖清单七字段表字段填什么什么算填完缺了这一列会怎样示例依赖编号与接口标识内部稳定编号；被调接口的名称和版本编号唯一，接口名称与提供方文档一致故障时无法在清单中快速定位DEP-018/支付扣款API/v3调用方系统本组织内调用该接口的系统名称能回指到该系统负责人不知道谁在调用，变更无法通知订单结算服务提供方与合约层级直接签约的提供方；该接口在提供方合同中的服务层级或套餐能回答“合同里有没有这条接口的SLA和配额承诺”配额和限流条款可能不在合同覆盖范围内某支付服务商，标准商户套餐业务用途与依赖强度接口支撑的具体业务流程；核心/重要/一般核心=中断阻塞关键流程；重要=可短时缓存或人工补偿；一般=可延迟所有依赖被同等对待，资源无法按关键度分配核心：支付扣款；订单确认前必须成功调用特征日均调用量、峰值倍率、调用时段至少有一周的实际调用数据无法判断限流余量和失效影响量级日均12万次，峰值3.2倍，促销日集中在2小时内失效影响接口不可用时，下游业务流程停多久、影响多少用户或金额写到可观察的后果，不写“影响业务”无法判断是否值得建备选方案不可用30分钟以上，下单流程阻断，影响约8%日订单降级与备选现状当前是否有降级路径或备选提供方；降级是否经过演练有具体路径描述，或明确写“无”清单显示“有备选”但实际从未切换过降级为异步队列，备选提供方未联调依赖强度分级不是一次性判断。同一接口在不同业务场景下的强度可能不同：支付扣款接口在正常下单时是核心依赖，在“订单状态查询”场景下可能只是一般依赖。依赖清单按调用场景分行，不按接口合并，避免一个接口多个用途时强度判断失真。二、接口失效：先分清“它挂了”和“只有你挂了”接口失效的识别最常见的错误是只记录“不可用”，不区分失效机制。2025年10月AWSus-east-1的故障是一个典型：DynamoDBAPI因DNS解析故障不可达，修复后EC2实例启动系统因依赖DynamoDB出现后续故障，网络负载均衡器健康检查又因EC2异常受损，进而波及Lambda和CloudWatch，AWS被迫对EC2实例启动和Lambda事件源映射处理采取限流措施，事件持续超过12小时。一个底层API的失效可以沿着依赖链传导到多个层面，而“接口挂了”这个描述无法告诉调用方：失效是从哪一层开始的、是否会级联、自己的调用在链路中的位置是否放大了影响。表3接口失效扫描清单识别问题失效机制评估入口什么算有识别对象识别记录示例接口是否有明确的SLA，SLA是否覆盖当前调用量级和时段可用性承诺缺口合同SLA条款或服务等级说明SLA写明了可用性百分比、补偿条件和测量口径SLA99.9%，但补偿仅覆盖订阅费，不含业务中断接口依赖的上游是否有级联风险，调用方是否位于依赖链的中间层级联失效提供方的架构说明或状态页历史提供方公开依赖链，或历史上出现过上游故障传导提供方状态页显示过去6个月有2次上游数据库故障导致的API不可用调用方是否对接口错误码做了区分处理，还是将所有非2xx统一重试错误处理失当调用方代码或网关配置能区分超时、连接失败、5xx、429、业务错误码当前配置对429和503均执行立即重试，无退避是否有超时和熔断配置，熔断阈值是否基于实际延迟分布客户端韧性缺口网关或客户端配置超时值有依据，熔断有滑动窗口和半开探测超时设为30秒，未设熔断，下游慢时线程池被占满是否有跨可用区或跨提供方的冗余，冗余是否经过切换演练单点集中架构文档和演练记录有冗余路径且有最近一次切换记录备选提供方已签约，但过去12个月未切换过提供方状态页和通知渠道是否在监控范围内，状态更新是否被纳入告警可观测性缺口监控配置状态页和提供方通知与内部告警关联状态页未接入监控，故障发生后由客服反馈才得知接口失效时是否有不依赖该接口的最小业务连续性路径业务连续性缺口业务连续性计划或降级预案有具体降级动作，且降级后业务可运行支付接口不可用时，降级为“稍后支付”，订单进入待支付队列式(1)外部暴露指数E=(V依赖÷V总)×(1−R内部)变量定义：E为外部暴露指数，取值0至1；V依赖为在给定时间窗口内，依赖该外部接口的调用量或业务量；V总为同一时间窗口内该业务流程的总量；R内部为内部冗余覆盖度，取值0至1，0表示该接口失效时没有任何内部降级或缓存路径承接，1表示接口失效时全部业务量可由内部路径承接。两个常见错误：R内部按“有降级预案”填1，但预案从未演练或降级后业务量承接能力不足；V依赖只算调用次数，不算该接口在业务流程中的位置——一个调用量小但位于支付确认必经路径上的接口，其业务暴露远高于调用量占比。校验方法：手里有依赖清单的调用量数据和业务流程数据；从清单“调用特征”和“降级与备选现状”两列取值；算出的E与表6的联合判定对照，E超过0.6且依赖强度为“核心”的接口进入优先缓解队列。示例：某支付扣款接口日均调用12万次，支付业务流程日均总订单15万笔，V依赖÷V总=0.8；该接口当前无内部降级路径（订单只能等待接口恢复），R内部=0，E=0.8。另一个物流查询接口调用量占比0.3，但有本地缓存可承接2小时查询，R内部=0.7，E=0.3×0.3=0.09。三、限流：配额不是合同承诺时，余量就是不确定的限流和接口失效是两类不同的风险。失效是“调用不成功”，限流是“调用被拒绝，但服务本身是正常的”。限流的识别要回答三个问题：配额是按什么口径计算的、当前余量消耗速度离触发还有多远、触发后调用方的行为是否会放大后果。2026年5月1日起，GoogleWorkspace调整了Gmail、日历和DriveAPI的用量配额，现有项目的配额至少在60天内保持不变，后续配额增加请求需要启用GoogleCloud结算功能，超出标准每日阈值时会产生费用。SAP在2026年4月更新的API政策中加强了限流、配额、数据进出和批量提取方面的控制。Anthropic在2026年4月调整计费政策，现有订阅不再覆盖第三方接入工具的调用额度，用户可购买流量包或通过API密钥继续使用。这些变化的共同特征是：配额和计费口径可以在合同期内调整，而调用方的容量规划往往基于调整前的假设。表4限流扫描清单识别问题限流机制评估入口什么算有识别对象识别记录示例配额是按调用次数、并发数、令牌量还是数据量计算配额口径提供方配额文档或合同附件能指出当前套餐的配额口径和具体数值按每分钟请求数计算，标准套餐600次/分钟配额数值是写在同一合同或SLA附件中，还是引用外部网页“以网站为准”配额确定性合同条款配额在合同或签署附件中有固定数值合同写“以提供方官网当前限额为准”，无数值过去30天的峰值调用是否达到配额的60%以上，峰值是否集中在特定时段余量消耗调用方监控数据有按小时或按分钟的调用量曲线日均调用量为配额的35%，促销日峰值达到配额的92%触发限流时，接口返回的是429并带Retry-After，还是静默丢请求或无明确信号限流信号质量接口文档或实际调用观测429响应包含Retry-After头或等价的重试时间指示返回429但无Retry-After，调用方只能固定间隔重试调用方收到429后的行为是退避等待，还是立即重试或持续打满客户端响应网关或客户端配置有指数退避，且退避上限合理当前为固定1秒重试，在限流期间持续打满配额配额调整的提前通知期是多久，通知是否写进合同变更通知合同条款或提供方政策合同或政策写明最低通知天数政策写明“至少提前60天通知”，但未写进合同超出配额后的计费或封禁规则是什么超限后果提供方政策或合同能回答“超限是加价、降级还是暂停”超出后按每千次加收费用，连续三日超限暂停当日调用式(2)配额余量消耗比Q=P峰值÷L配额变量定义：Q为配额余量消耗比；P峰值为过去30天内按最细可用粒度（分钟或小时）统计的峰值调用量；L配额为同一粒度下的配额上限。Q越接近1，余量越薄。两个常见错误：P峰值用日均值乘以峰值倍率估算，没有使用实际按分钟或按小时的调用数据；L配额取的是“购买配额”而不是“标准配额”，忽略了超额部分可能触发加价或封禁而不是自动扩容。校验方法：手里有调用方监控的按分钟或按小时调用量数据和提供方的配额文档；确认配额口径与调用量统计口径一致（都是请求数，或都是令牌量）；算出的Q超过0.8且配额不在合同固定条款中的依赖，进入限流优先缓解队列。示例：某身份核验接口标准配额为600次/分钟，促销日实测峰值达到552次/分钟，Q=552÷600=0.92。该配额写在提供方官网的“当前限额”页面，合同未固定数值，提供方政策允许提前60天通知后调整。Q=0.92叠加配额不确定，该依赖在表6中被判定为“限流×条款”交叉命中。四、条款变更：通知期和变更范围是两条独立的防线条款变更风险的识别容易被简化为“有没有通知”。通知期解决的是“有没有时间反应”，变更范围解决的是“通知之后能不能拒绝或退出”。合同里写30天通知，但变更范围条款允许提供方“随时修改服务功能、配额或定价”，30天通知只给了调用方搬家时间，没有给谈判空间。第三方API提供方可能单方面更改API端点、弃用功能、修改技术要求、引入使用限制或调整定价和访问模型。SaaS合同中常见的危险信号包括：宽泛的自由裁量条款（“可随时修改服务”）、将限流标准引用到外部文档（“以当前文档或网站为准”）、缺少服务补偿（提供方降低容量不承担财务后果）。表5条款变更扫描清单识别问题条款维度评估入口什么算有识别对象识别记录示例合同是否允许提供方单方面变更服务功能、API端点或弃用功能，变更范围是否有边界变更范围合同服务变更条款条款写明了变更的允许范围和排除项条款写“可基于安全或性能原因修改API”，但“安全或性能”无定义变更的提前通知期是多久，通知是否以书面形式发出通知期合同通知条款写明最低天数且通知方式可追溯30天书面通知，但未约定通知到达的确认方式配额或限流标准的变更是否受通知期约束，还是归入“技术调整”不受通知约束配额变更覆盖合同条款与配额条款的交叉配额变更明确受通知期约束合同将限流调整归入“技术文档更新”，不受30天通知约束调用方在收到变更通知后是否有拒绝权、终止权或价格保护退出与救济合同终止条款和价格条款有终止权且无需支付剩余期限费用，或有价格锁定只有终止权，但需支付剩余合同期费用弃用功能或API版本下线是否有过渡期，过渡期内旧版本是否继续可用版本弃用合同或提供方弃用政策过渡期有明确时长且旧版本在过渡期内保持功能政策写“提前6个月通知弃用”，但未承诺过渡期内不降低配额服务补偿是否覆盖配额降低或功能弃用导致的业务中断补偿范围合同SLA补偿条款补偿触发条件包含容量或功能变化，不只是完全不可用补偿仅针对可用性低于99.9%，不覆盖配额下调合同是否引用外部文档作为限流或服务标准的依据外部引用风险合同限流条款限流数值和调整规则在合同或签署附件中固定合同写“限流以提供方开发者文档为准”，文档可随时更新条款变更的“有识别对象”不取决于合同是否写了“可以变更”，而取决于变更范围、通知期、退出权和补偿范围四项中是否有足够组合让调用方在变更发生时不只是被动接受。仅有通知期而没有退出权或价格保护的条款，对条款变更风险的缓解有限。式(3)单方面变更敞口指数T=(C范围+C配额+C退出)÷3变量定义：T为单方面变更敞口指数，取值0至1；C范围为变更范围敞口，合同允许单方面变更且范围无明确边界=1，有边界但边界模糊=0.5，范围明确受限=0；C配额为配额变更敞口，配额变更不受通知期约束或配额引用外部文档=1，受通知期约束但无数值固定=0.5，配额在合同中固定且变更需双方同意=0；C退出为退出权缺口，收到变更通知后无终止权或终止需支付剩余费用=1，有终止权但需支付部分费用=0.5，有终止权且无惩罚=0。T越高，条款对调用方的保护越弱。两个常见错误：只检查“有没有通知期”就判定条款风险低，没有看通知期覆盖的范围（配额变更可能被排除在通知义务之外）；把“有终止权”等同于退出能力，忽略了终止权附带的剩余合同期费用。校验方法：手里有合同文本和提供方政策文档；逐项核对三个维度并取分；算出的T超过0.6的依赖，在表6中与工程侧的失效或限流信号交叉，决定是否需要在下一轮合同谈判中提出修订。示例：某API合同允许提供方“基于安全原因修改API”，范围无定义（C范围=1）；配额调整归入“技术文档更新”，不受30天通知约束（C配额=1）；调用方有终止权但需支付剩余期限费用（C退出=1）。T=(1+1+1)÷3=1.0。该依赖的条款保护接近于零，任何单方面变更都只能事后应对。五、三类风险联合判定：同一依赖可能同时命中三条接口失效、限流、条款变更在同一依赖上不是互斥的。一个接口可能在促销日触发限流，同时其配额标准引用外部文档不受通知期约束，而失效时的业务暴露又很高。联合判定的目的是识别哪些依赖需要同时做工程缓解和合同缓解，而不是在两条线上各自记录、互不关联。表6三类风险联合判定表联合条件需要的信号组合判定优先动作示例失效×核心E≥0.6且依赖强度为“核心”工程优先先建降级路径或备选提供方，再补SLA支付扣款接口E=0.8，核心，先做异步队列降级限流×配额不确定Q≥0.8且配额不在合同固定条款中合同与工程并行工程侧做客户端限流和退避；合同侧争取配额固定或更长通知期身份核验Q=0.92，配额引用官网，两侧同时动作条款×高敞口T≥0.6且该依赖为“核心”或“重要”合同优先在续签或补充协议中修订变更范围、退出权或补偿条款T=1.0的核心依赖，续签时必须改条款三条交叉同一依赖同时命中“失效×核心”“限流×配额不确定”“条款×高敞口”中的两条及以上升级评估列为“集中暴露依赖”，在管理层报告中单独列示，指定一名负责人统筹工程和合同两侧的缓解某支付渠道同时E=0.7、Q=0.85、T=0.8单条命中但后果可接受只有一条命中，且依赖强度为“一般”或有有效降级记录观察不进入优先缓解队列，清单保持更新某天气查询接口只有限流信号，但有本地缓存，记录观察联合判定后的输出不是一张新的汇总表，是在依赖清单的每条记录上增加“联合判定结果”一列，值为“工程优先”“合同与工程并行”“合同优先”“升级评估”“记录观察”之一。同一依赖的联合判定结果发生变化时（例如Q从0.7升到0.85），触发重新判定，不需要等到下一轮全量评估。六、识别做了一轮就停在清单上，先查这五处依赖清单在第一个月填完之后，第二个月开始只增加新接口、不更新评估字段，按表7顺序查。第一检查点不打开依赖清单，先打开过去一个季度的接口故障记录和提供方通知。表7停摆排查表检查点打开什么看什么什么算正常不正常时怎么改一过去一个季度的接口故障记录和提供方通知每次故障或通知是否在依赖清单中有对应的评估更新故障或通知后清单的“失效影响”或“降级现状”有更新记录补录评估更新，标注“故障驱动更新”二表2“降级与备选现状”列写“有备选”的依赖中，过去12个月实际切换过的比例有备选的依赖至少有过一次切换记录或演练记录未切换过的“有备选”改为“未验证”，并安排演练三式(2)的Q值是否有依赖的Q在上升但没有重新判定所有Q≥0.8的依赖在最近一个季度内重新判定过逐条重算Q并更新联合判定四合同中的变更通知条款过去一个季度提供方发出的变更通知是否被记录并评估影响每份变更通知有对应的依赖影响评估补评估，更新T值五依赖清单的复核日期是否有超过一个季度未复核的关键依赖核心和重要依赖每月或每季度复核按风险等级恢复复核周期示例：检查点一发现过去一个季度有3次提供方限流政策调整通知，依赖清单中只有1条有对应的评估更新。补评估后发现其中一条通知将某接口的配额计算口径从“请求数”改为“令牌量”，而调用方的Q值是按请求数算的，实际令牌量消耗已经达到新口径配额的110%。该依赖的联合判定从“记录观察”改为“升级评估”。七、什么时候加备选、什么时候改合同：四条规则和一处矛盾决策规则：规则一：如果某依赖的E≥0.6且依赖强度为“核心”，且当前R内部=0，则在下一个业务周期内至少建立一条不依赖该接口的降级路径或缓存承接路径；如果降级路径无法在业务周期内建成，在依赖清单中记录“暴露未缓解”并指定一名高管知会，降级路径的建成日期不晚于下一次大促或业务峰值前30天。规则二：如果某依赖的Q≥0.8且配额不在合同固定条款中，工程侧在两周内上线客户端限流器，限流阈值设置为“按提供方配额口径计算、保留至少15%余量”；合同侧在续签或补充协议中争取将配额数值写入合同附件，或争取不少于90天的配额变更通知期。工程侧动作不等待合同侧结果。规则三：如果某依赖的T≥0.6且属于“核心”或“重要”，在续签时至少修改以下一项：变更范围限定（排除配额和定价变更，或要求变更需双方同意）、退出权无惩罚、或服务补偿覆盖配额降低和功能弃用。如果提供方拒绝修改且该依赖无法替换，记录“条款风险已接受”，由业务负责人和法务共同签署，并在依赖清单中标记“接受日期”和“下一次复核日期”。规则四：如果某依赖同时命中三条中的两条及以上（“集中暴露依赖”），指定一名单一负责人统筹工程和合同两侧的缓解动作，该依赖在管理层报告中单独列示；如果同一提供方下有两条及以上依赖被判定为“集中暴露”，在提供方层面评估集中度风险，考虑是否需要调整该提供方的总体依赖量。矛盾陈述：工程侧缓解（降级路径、客户端限流、多提供方路由）可以在几周内上线，但只解决“失效或限流发生时不至于停摆”，不解决“提供方可以随时改变规则”；合同侧缓解（配额固定、通知期、退出权）能约束规则变更，但谈判周期以月计，且提供方在标准条款上让步的空间有限。先做工程还是先改合同，资源投在哪一侧，没有同时满足两条的选项。实质分析：工程缓解和合同缓解覆盖的是不同时间尺度上的风险。工程缓解在变更或失效发生时生效，它缩短的是恢复时间；合同缓解在变更发生前生效，它缩短的是“你是否有权拒绝或退出”的窗口。对于配额和限流，工程侧的客户端限流器在两周内可以降低触发限流的概率，但无法阻止提供方单方面把配额从600降到300；合同侧的配额固定条款能阻止单方面降配额，但谈判和签署可能需要一个季度。两侧都不能替代另一侧。DORA对关键第三方的要求也指向同一方向：不仅要求合同中有审计权和终止权，还要求测试连接韧性、有备份供应商或回退安排。权衡规则：按风险类型分配首轮资源。接口失效风险以工程缓解为主，因为失效的触发不依赖合同，恢复速度由调用方的降级和切换能力决定；限流风险工程与合同并行，工程侧先做客户端限流和退避，合同侧争取配额固定；条款变更风险以合同缓解为主，因为工程侧无法阻止规则被修改。对于“集中暴露依赖”，工程和合同两侧的动作由同一负责人排期，不因为合同谈判周期长而延迟工程侧的上线。退路：如果某核心依赖的E≥0.6、Q≥0.8且T≥0.6，三条同时命中，而工程侧备选方案在业务周期内无法建成、合同侧提供方拒绝修改条款，该依赖转为“接受并监控”状态：在依赖清单中记录接受理由、接受人和复核日期；监控频率从季度提高到每月；在下一次提供方合同续签窗口必须重新提出条款修订，不接受连续两个续签周期不做修改。八、完整版、精简版、极简版按依赖关键度选依赖数量在20条以上、有核心支付或身份类依赖的组织走完整版；依赖数量在10至20条、核心依赖较少或已有部分降级的走精简版；依赖数量在10条以内或刚建立清单的走极简版。三套版本的差异写在表8。表8三套场景表场景跑什么用哪个公式不能妥协的底线修复后重跑什么完整版表2七字段、表3七项、表4七项、表5七项、表6联合判定、表7五项排查式(1)、式(2)、式(3)核心依赖有E和Q的数值，至少有一条缓解动作在推进；T≥0.6的核心依赖有合同修订计划或具名接受全量重跑：表7五项、E/Q/T值、联合判定结果精简版表2前五字段（不含降级现状的演练记录）、表3前五项、表4前五项、表5前四项、表6前三条联合条件、表7前三项式(1)、式(2)核心依赖的E和Q有数值；Q≥0.8的依赖有客户端限流或合同通知期动作只重跑表7前三项和核心依赖的E/Q极简版表2中依赖编号、调用方、业务用途与依赖强度、降级现状四字段；表3中SLA和降级两项；表4中Q值和限流信号两项；表6中“失效×核心”一条式(1)和Q的简化计算（峰值÷配额）每条核心依赖有降级路径或“无降级”的明确记录；每条依赖的Q可计算只重跑核心依赖的降级现状核对和Q值重算完整版适用于需要向审计或监管说明“关键第三方依赖是否可中断、是否有回退安排”的组织。精简版去掉条款变更的定量评分（T值），保留变更通知记录和配额条款检查，适合尚未建立合同集中管理能力的团队。极简版的核心不是完成三类扫描，是先回答两个问题：哪条核心依赖在失效时没有降级路径，哪条依赖的配额余量已经薄到经不起一次峰值。完整案例：某平台工程负责人的第一轮第三方API依赖识别示例案例，细节为合理设定。起点：平台调用34个外部API，依赖清单只有“接口名称、提供方、负责人、状态”四列。上个月发生两件事：支付渠道A将单笔限额从50万元降到5万元，导致大额订单支付失败；身份核验接口B在促销日返回429，客服收到约200条“无法完成验证”的反馈。第一轮试错。按“接口是否可用”逐条检查，34个接口中32个标记“正常”，2个标记“异常”（支付渠道A限额变化、身份核验接口B促销日限流）。信号：标记“异常”的两条都没有对应的缓解动作——支付限额变化没有通知大额用户改走其他渠道，身份核验在促销日没有客户端限流，调用方仍以固定间隔重试。当时以为问题是“异常接口太少，说明整体可控”，试了只处理两条异常，下一周支付渠道C的条款更新通知到达，将某接口的免费调用额度削减了60%，清单上该接口仍然是“正常”。新信息：清单的“状态”列只反映“接口此刻是否可调通”，不反映“规则是否已经改变”和“余量是否已经不够”。推翻“状态正常即无风险”的假设，换路：把清单从“状态视图”改为“三类风险视图”，每条依赖分别填失效、限流、条款三个维度的识别字段。第二轮试错。按表3至表5逐条补三类字段。信号：补到限流维度时发现，身份核验接口B的配额写在提供方官网的“当前限额”页面，合同没有固定数值；促销日峰值Q=0.92；调用方对429的响应是固定1秒重试，没有退避。补到条款维度时发现，支付渠道A的合同允许提供方“基于风险控制调整交易限额”，通知期只有7天，且调用方没有终止权豁免。当时以为问题集中在“限流”，试了只给接口B加客户端限流，下一周支付渠道A的限额调整再次发生，没有提前7天通知（通知在变更后第三天到达），调用方仍然没有合同依据。新信息：限流和条款是两条独立的线，客户端限流不能约束提供方修改配额，合同通知期不能替代客户端退避。推翻“限流是主要问题”的假设，换路：按表6做联合判定，把每一条依赖的失效、限流、条款信号合起来看。第三轮试错。联合判定后，支付渠道A被判定为“条款×高敞口”（T=1.0：变更范围无边界、配额变更不受通知约束、终止需付剩余费用）且E=0.7（大额支付路径无内部降级），属于“集中暴露依赖”；身份核验接口B被判定为“限流×配额不确定”（Q=0.92，配额引用官网），同时T=0.5（有30天通知但无数值固定）。信号：两条“集中暴露依赖”分属两个提供方，但支付渠道A的合同还有8个月到期，合同侧修订无法在本次业务周期内完成。当时以为合同侧做不了就只做工程侧，试了给支付渠道A加备选通道，备选通道联调需要6周，而大额支付峰值在4周后。新信息：工程侧的备选建设周期可能长于风险窗口，合同侧的“接受”需要具名，不能默认拖延。推翻“工程侧总能兜住”的假设，换路：对支付渠道A，工程侧立即上线“大额支付分流提示”（在限额接近时引导用户走备选通道，备选通道未完全联调前先做人工审核兜底），合同侧在续签窗口提出变更范围限定和终止权无惩罚；对身份核验接口B，工程侧两周内上线客户端限流（保留15%余量）和指数退避，合同侧在续签时争取配额数值写入附件。第四轮试错。动作推进后重跑表7。信号：检查点二发现依赖清单中写“有备选”的7条依赖，过去12个月实际切换过的只有1条；检查点四发现过去一个季度有5份提供方变更通知，只有2份有评估记录。当时以为“有备选”写在清单上就算缓解，试了不补切换演练，下一次支付渠道C的额度削减发生时，备选通道因为从未演练，切换后出现签名验证失败，业务中断了40分钟。新信息：“有备选”和“备选可用”是两个状态，未经演练的备选在切换时可能引入新的失效。推翻“有备选即缓解”的假设，换路：把“有备选”改为“已演练”和“未演练”两档，未演练的备选在下一个业务周期内安排一次切换演练，演练通过后才计入R内部。终点：34条依赖中，核心依赖9条，全部有E和Q的数值；支付渠道A判定为“集中暴露依赖”，工程侧大额分流已上线，合同侧续签修订已排期，接受记录已签署（接受人：业务负责人+法务，复核日