AI 产品更新后，如何检查不同地区的 API 请求是否正常

产品更新后的回归，难点不在跑通，而在证明“还是原来那样”。先把“正常”拆成成功率、响应结构和耗时三类可判定指标，再固定请求、版本与地区，用发布前后、地区之间的对照排除波动。不同地区的回归要借助代理 IP 把出口切过去，否则“地区差异”和“发版差异”会混在一起。测试只在自有应用和测试账号中进行，涉及跨境访问时以目标服务的授权范围为准。

怎么判断 API 更新后仍然正常？

“正常”不是一次请求返回 200，而是三项可以量化的结果。

• 成功率：同一请求集在目标地区的成功比例。
• 响应结构：字段、类型、必填项是否与更新前一致。字段静默缺失比直接报错更难发现。
• 耗时分布：看 p50 和 p95，不看单次最快值。

三项都要在更新前测出基线，否则更新后没有比较对象。样本量和观察窗口应按请求波动、风险和团队基线设定；样本较少时，把结果标为初步观察，不作确定归因。

哪些条件需要在更新前后保持一致？

对照前先锁定四类条件，并逐次记录实际值：

• 变量：版本 ｜ 需要固定：每次请求实际命中的应用 build、依赖与上游版本/标识 ｜ 容易忽略的点：灰度期间同一请求可能落到不同版本
• 变量：地区 ｜ 需要固定：国家、城市、出口 IP ｜ 容易忽略的点：只写国家，定位会漂到邻近城市
• 变量：请求 ｜ 需要固定：URL、请求体、header、账号 ｜ 容易忽略的点：换账号等于换权限，结果不可比
• 变量：客户端 ｜ 需要固定：SDK、HTTP 客户端、超时、重试 ｜ 容易忽略的点：重试次数不同，成功率会被补高

发布前后的对照要落到 2x2 矩阵：更新前与更新后、地区 A 与地区 B。只有一格缺失，就无法判断差异来自版本还是地区。

• 单元格：更新前 × 地区 A ｜ 要记录的内容：版本号、出口、成功率、响应结构、p50 与 p95
• 单元格：更新前 × 地区 B ｜ 要记录的内容：同上，与 A 使用同一请求集和相近时间窗口
• 单元格：更新后 × 地区 A ｜ 要记录的内容：同上，版本号与请求集保持不变
• 单元格：更新后 × 地区 B ｜ 要记录的内容：同上，出口尽量与更新前同一地区一致

地区、版本或时间窗口无法全部覆盖时，在结论里直接写出缺哪一格、缺的原因，以及它能带来多大不确定性；缺失的格子不能靠推断补齐。

怎么确认代理 IP 出口确实位于目标地区？

地区对照首先要确认请求实际走的出口路径。使用与被测 API 相同的客户端和代理配置核验，并检查 NO_PROXY 与路由；独立运行的本机 curl 可能走不同路径。

分别记录 IP 查询库结果、目标服务看到的源 IP/地区判断和业务 locale。语言、时区与币种可能来自用户偏好，不能证明物理位置；来源冲突时并列记录并标记为定位不一致。下表用于让后续复测沿用相同字段：

• 字段：出口 IP ｜ 示例：203.0.113.24 ｜ 用途：确认复测时没换出口
• 字段：ASN 与组织 ｜ 示例：AS64500（文档占位值），某云机房 ｜ 用途：仅作辅助线索
• 字段：城市 ｜ 示例：目标城市，或邻近城市 ｜ 用途：记录数据库定位结果
• 字段：服务端识别 ｜ 示例：源 IP、地区标签与判定时间 ｜ 用途：记录该服务的识别结果

同一地区可用两个出口做配对复测。结果变化只说明出口或路径相关因素可能参与；固定账号、请求、客户端和时间窗口重复测试，再结合链路与服务端证据判断。ASN、组织和数据库标签不能单独证明住宅/机房属性或物理位置，示例中的 AS64500 是文档保留号。

怎么判断问题来自版本、地区策略还是网络？

归因时按证据形成候选方向：

• 更新前后有差异：核对实际 build、请求契约和配置。
• 同一时段不同地区有差异：核对服务端错误、账号/模型范围及代理路径。
• 连接或 TLS 阶段变化：结合阶段日志和重复样本检查链路；TTFB 也包含上游处理。

同时核对链路、版本和服务端证据；仍不明确时保留未决。

若测试伴随地区版本灰度，可参考国际站按地区灰度发布时，如何观察错误率并判断是否回滚？。

出现哪些情况应立即停止测试？

测试前先写清通过条件、失败阈值、最长运行时间和请求上限，再开始跑样本。出现下面任一情况，停测优先于补样本：

• 影响非测试账号：立即停测，回滚配置，复盘调用链是否串了账号。
• 费用超出预算：停止请求，核对计费口径，再决定是否继续。
• 目标服务拒绝授权，且提示地区或权限：不要连续重试，先核对可用范围。
• 日志出现未脱敏的凭据：停止测试，按凭据泄露流程处理。

停止测试后，保存最后一轮的脱敏请求与响应头、出口 IP、发生时间和当时版本，便于复现异常并核对灰度或配置变化。

更新通过后，还要怎么验证回滚？

通过的标准是三件事同时成立：基线可复现、更新后达标、回滚路径已验证。只满足前两项时，只能记为“待观察”，不能记为通过。

回滚不是“把版本改回去”这一件事，要同时覆盖应用版本、配置开关和流量比例。只改版本、不改配置，经常出现“版本回去了、行为没回去”。

回滚后重跑矩阵中更新前的对照格，并按基线和批准的 API 契约检查成功率、响应结构及 p95 耗时。回滚演练是否作为放行门槛，应由团队预先确定；指标未恢复时先记为未通过或待归因，再核对命中版本、配置/缓存、上游状态、样本量和时间差。

FAQ

Q：测试地区必须覆盖所有国家吗？

A：不必，优先覆盖业务实际使用地区和近期变更影响地区，并记录抽样依据。

Q：上游 API 更新但没有版本号，怎么确定比较范围？

A：记录测试时间、模型标识、请求参数和响应头，按同一时间窗口做前后对照。

Q：地区测试通过后能否直接全量发布？

A：不能仅凭地区测试决定；还需结合灰度指标、监控和回滚条件判断。