一、项目背景

这个 AI 网关下游接了好几个模型，平时好好的，但偶发会返回残缺的 JSON 或者干脆一段乱码，上游业务拿到就直接解析崩溃，报错堆栈满天飞。最要命的是故障发生时，业务方和模型方互相甩锅，业务说模型坏了，模型方说网关链路有问题，排查半天发现是某个模型在特定输入下输出截断。我们进场时，这类"偶发但致命"的异常已经影响过两三次大客户的调用。结论很清楚，网关不能只做转发，得在出网前把响应校验这道关，残缺和乱码挡在里面，别甩给上游背锅。

网关下游接了好几个模型，平时稳，偶发返回残缺 JSON 或乱码，上游业务解析直接崩溃。最要命的是故障发生时业务和模型方互相甩锅，业务说模型坏，模型方说链路问题，排查半天发现是某模型特定输入下输出截断。这类偶发但致命的异常已经影响过两三次大客户调用，结论很清楚，网关不能只转发，得出网前把响应校验这道关。

二、落地场景

新方案在网关出网前加了一层响应 schema 校验，下游模型返回的 JSON 必须先过结构校验，字段缺失、类型不对、格式残缺的直接判为异常。异常响应不外传，而是触发兜底重路由，把同一个请求发给备用模型再试一次，两次都失败才向上游返回明确的错误，而不是一段乱码。同时给每次异常打故障归因标签，标记是格式问题、截断还是超时，方便区分是模型问题还是链路问题。上游业务拿到的要么是正常结果，要么是一个清晰的错误码加原因，再也不会因为解析崩溃而雪崩。

响应 schema 校验在出网前挡一道，字段缺失类型不对格式残缺直接判异常。异常不外传，触发兜底重路由把同请求发给备用模型再试，两次都失败才返回明确错误而非乱码。每次异常打故障归因标签，区分格式问题截断还是超时，方便分清模型侧还是链路侧。上游拿到要么正常结果要么清晰错误码加原因，再不会因解析崩溃雪崩。

三、关键技术挑战与解决思路

响应 schema 校验要兼顾严格和灵活，太严会误杀正常但字段顺序变化的返回，太松又拦不住残缺，我们按业务必需字段做校验，可选字段宽松处理，把误杀压到最低。残缺响应拦截最怕漏判，乱码和截断往往没有标准特征，我们用结构校验加内容合理性双重判断，比如 JSON 解析失败或者关键字段为空就判异常。异常兜底重路由要控制次数，避免一个坏模型把备用也拖死，我们设了单请求最多一次重路由，并且重路由避开同源实例。故障归因打标是排障的关键，标签区分模型侧和链路侧，谁的问题一目了然，再也不会扯皮。

校验我们按必需字段严、可选字段松，太严误杀正常变体，太松拦不住残缺，这个度调了很久。残缺判断用结构校验加内容合理性双重，JSON 解析失败或关键字段空就判异常。兜底重路由限单次且避开同源实例，防止坏模型拖死备用。故障归因打标是排障关键，标签直接指明方向，再也不会扯皮。这几步合起来才把偶发异常变成可控。

四、效果数据

异常响应拦截率做到满分，所有残缺和乱码在出网前被拦下，上游解析崩溃次数从每月几十次降到零。兜底重路由成功率约八成，也就是八成的异常通过备用模型拿到了正常结果，用户无感。故障定位时长从原来平均半小时缩短到几分钟，因为归因标签直接指明方向。我们复盘时算过，这一层校验挡住的不仅是崩溃，更是一次次潜在的大客户投诉，投入产出比很高。

异常响应拦截率满分，残缺乱码在出网前拦下，上游解析崩溃从月均几十次降到零。兜底重路由成功率约八成，八成异常经备用模型拿到正常结果用户无感。故障定位时长从平均半小时缩到几分钟，归因标签直接指明方向。我们复盘算过，这层校验挡住的不只是崩溃更是一次次潜在大客户投诉。

五、可复用经验总结

网关要在出网前把响应校验这道关，残缺和乱码挡在里面，别甩给上游背锅，我们是被两次大客户解析崩溃逼出这套校验的，这个教训够贵。校验别太严，必需字段严、可选字段松，误杀比漏判更伤业务，这个度我们调了很久。兜底重路由一定要限次，避开同源，否则坏模型能把备用也拖下水。下一步想把常见坏模式做成样本库，让校验能识别更多隐性异常，而不只靠结构判断。

案例片段（已脱敏）： 响应校验片段：网关出网前对 JSON 响应做 schema 校验，缺必需字段即判异常并触发重路由（限 1 次，避开同源实例）。某周统计：格式异常占 62%、截断占 28%、超时占 10%；兜底重路由成功率 81%；上游解析崩溃由月均 34 次降至 0；故障定位平均时长由 31 分钟降至 4 分钟。

网关要在出网前把响应校验这道关，残缺乱码挡里面别甩上游背锅，我们是被两次大客户解析崩溃逼出这套校验的，这个教训够贵。校验别太严，必需严可选松，误杀比漏判更伤业务，这度调很久。兜底重路由一定要限次避同源，否则坏模型拖死备用。下一步把常见坏模式做样本库，让校验识别更多隐性异常不只靠结构。