14 个接口全 404，后端日志却一条没有——多后端路由写错了
联调阶段，某模块前端页面一打开就全红：所有请求返回 404。第一反应是后端接口没部署好，去翻后端日志——什么都没有，不是没有报错，是完全没有收到请求。
诡异的地方在于：前端代码逻辑写对了，接口文档上的路径也对，请求甚至发出去了，Network 面板能看到请求，只是打到了一个压根不认识这条路由的服务上。
现象
- 前端调用 14 个 API，全部 404
- 后端（PHP）日志零请求记录
- 浏览器 Network 面板可见请求，HTTP 状态 404 来自另一个后端（Java）
- 前端代码功能逻辑无误，路径拼写无误
根因
项目是 PHP + Java 混合双后端架构，各自有独立的 baseURL 配置：
// settings.js
phpBaseUrl: 'https://api.example.com/php', // PHP 后端
baseUrl: 'https://api.example.com/java', // Java 后端前端封装了两个 HTTP 客户端实例：
import subapiHl from '@/api/subapiHl' // → PHP 后端
import subapiCM from '@/api/subapiCM' // → Java 后端这个模块的接口写在 PHP 后端，但前端开发者统一 import 了 subapiCM（Java 客户端），导致 14 个请求全部打到 Java 服务。Java 服务不认识这些路由，统一返回 404。
根因不是代码错误，而是派发任务时没有标明「接口部署在哪个后端」，Review checklist 里也没有「HTTP 客户端来源 vs 后端部署位置」这一项。问题穿越了开发、两轮 Code Review、场景 Review、两轮修复、测试，到最后人工兜底才被发现。
baseURL 不同的两个 HTTP 客户端实例在 IDE 里长得一模一样，自动补全、类型检查、lint 全都不会报错。请求确实发出去了，只是发到了错误的服务——错误服务返回 404，正确的服务永远收不到请求，日志一行没有。这类问题极难靠 Review 肉眼察觉，必须在任务派发阶段就把后端归属锁死。
正解
任务派发时显式指定后端归属和客户端标识，而不是让前端开发者自行猜测：
本功能 API 部署在 PHP 后端，前端必须使用 subapiHl 客户端调用。
import 示例：import subapiHl from '@/api/subapiHl'
调用示例：subapiHl.getAjax('get', 'doc/xxx/list', params)
Review 时增加一条基础设施路由检查：
[ ] 前端 import 的客户端（subapiHl / subapiCM）与接口实际部署的后端匹配？
[ ] 同目录下其他 API 文件用的是哪个客户端？是否一致？
[ ] 浏览器 Network 面板请求 URL 的 host 是否正确？
[ ] 后端日志确认收到请求？
新增 API 文件时的经验法则：同目录下已有文件 import 的是哪个客户端，新文件大概率也应该一致——不一致时必须主动确认，而不是默认跟着写。
在任务描述里明确「接口在 PHP/Java」+ 「前端用 subapiHl/subapiCM」，让这个决策从脑子里外化到 prompt 和 checklist，而不是靠开发者的经验隐式推断。Review 阶段把「客户端路由正确性」列为前三项必检，而不是只看业务逻辑。
一句话外卖
多后端架构下，HTTP 客户端路由错误是一类纯基础设施级的静默错误，业务逻辑再对也白搭——必须在任务描述阶段就把后端归属和客户端标识显式锁定，不能依赖 Review 的肉眼发现。