yuetsh
967e9ef7f7
feat: 路由遮蔽检查脚本；切换前把前后端接口逐条对了一遍
## 切换前核对：前端调的接口后端有没有漏
写脚本把前端 224 个调用点和后端注册的路由逐条比对。**零缺口** —— 唯一报出来的
一条是我的正则被嵌套括号截断了（`users/${encodeURIComponent(...)}/badges`），
后端那条路由是有的。「后端有、前端没调」那 25 条也逐个看过，全是脚本的假阳性
（把 `.get("user")` 这类非路由调用当成了路由）和假阴性（前端用三元表达式拼路径，
正则看不见，比如 `GET /me` 其实在 shared/api.ts 里被调）。
结论是没发现缺口，但这个脚本不够可靠、不足以证明"一定没有"，所以没留进仓库。
## 路由遮蔽检查（留成常驻脚本）
比"有没有漏"更值得防的是遮蔽：**Hono 按注册顺序匹配，不是静态优先**。
`/problems/:id` 注册在 `/problems/random` 前面的话，后者永远进不去 ——
不报错、不警告，只是静默走进前一条的 handler。阶段 4 真实发生过一次，
两个教师用的分析端点被吃掉，一直到评审才发现。
全仓 167 条路由按真实注册顺序扫：**零遮蔽**。
这个结论敢下，是因为检测器本身也验了：
- 自检用例里放了阶段 4 那个历史真实案例，能抓到；边界（两边都是参数、
段数不同、不同前缀）不误报
- 核对了 24 个 router 全在扫描范围内，没有漏扫
- 反向验证：往 problem.ts 末尾加一条注册在 `:displayId` 之后的字面量路由，
脚本立刻报出来并 exit 1
未经验证的检测器报"没问题"是没有意义的 —— 这个教训今天已经吃过两次
（tree-sitter 那次、SQL 内存那次）。
脚本落在 apps/api/src/scripts/check-route-shadowing.ts，
`bun run --filter '@oj2/api' check:routes`，加完路由跑一下。
CLAUDE.md 里也写了。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-08 03:42:37 -06:00
..
2026-08-08 03:42:37 -06:00
2026-08-08 02:23:23 -06:00