多模型路由报错怎么解决

路由层一出问题，报错往往长得一样：有时是 400，有时是 502，有时干脆没返回。线上只看到一句「请求失败」，很难判断是自己的拼装逻辑、某个渠道的配置，还是上游在限流。这篇按「报错类型 → 逐层定位 → 收敛动作」给一条排错路径，让你在日志里先分清是哪一层出的事，再决定改代码还是换渠道。

路由层一出事，报错信息常常长得一样：有时是 400，有时是 502，有时干脆连接被断。线上只看到一句「请求失败」，很难立刻判断是自己的拼装逻辑写错了、某个渠道配置漂了，还是上游正卡在限流。先别改代码，先给报错归个类，再一层一层往里剥。

这篇给搭多模型路由的开发者一条排错顺序：按报错类型分层定位，从请求形状、渠道配置到上游限流逐层缩小范围，最后把偶发问题变成能看出来的可观测问题。判断标准会写清楚，什么情况下这套分层不适用也会点明。

先把报错分成四类，别一上来就改代码

路由报错最怕混着修。同一个「请求失败」，可能是字段拼错，也可能是渠道挂了。先按下面四类归位，归类错了，后面怎么改都是白费。归类的依据是报错内容加复现规律，不是状态码本身。

分层的目的不是多绕几步，而是每一步都能拿到二选一的结论：问题在里层还是外层。按下面顺序走，一旦某层通过了，就说明它往里都正常，继续往外剥就行。

第三层最容易漏：不同渠道对同一个模型的命名和参数要求未必一致，映射表里对不上的时候，报错往往被归成「请求形状类」，实际改的却是配置。这一层对完仍旧不通，再去看上游状态。

如果前面已经确认故障在分发规则这一层，就按清单逐条过。检查重点不是规则写得多漂亮，而是它有没有制造回环、有没有只测了一半、有没有让慢渠道拖累快渠道。

并发与超时的具体参考值没法一刀切，跟你的请求长度、渠道响应速度都有关。要横向对比各渠道的实际表现，到、/tools/speed-test 这类站内工具页看当时的数字，再决定按渠道怎么分档。

排错排到最后，最常见的结局是「偶尔还会崩，但抓不到」。这时候问题不在代码，而在日志记的信息不够。日志里至少要有渠道标识、模型名、状态码和耗时，缺一项，事后就复不了盘。

同一段代码换了个渠道就 400，是路由写错了吗？

多数不是路由分发的问题，而是两个渠道对同一模型的参数要求不同：有的不接受某些字段，有的要求字段嵌套层级不一样。先把请求体原样打到新渠道单独测一次，对照两边的字段说明，再决定在路由层做字段裁剪还是改造调用方。

偶发失败到底算上游问题还是自己的问题？

看失败是否与请求内容相关：同一请求重试能过，多半是限流或上游抖动；每次都挂在同一个模型或同一类长请求上，更可能是自己这层的超时或并发设置不合理。把失败样本按渠道和耗时分开统计，比看整体成功率有用。

降级切到备用渠道后还要不要继续报错？

降级本身应该吞掉错误，但要把切换事件记进日志，否则你会以为备用渠道一直很稳。另外备用渠道的能力和参数未必和主渠道一致，切换后返回结构变了，调用方也得能兼容，这一点要在接入时就验证。