发布后发现控制台每次请求打印 3 条调试日志，一天累积 200 多行。代码里还有 6 处 TODO 和一处写死的测试账号。日志里能对上时间点，这种反而好排。
调试代码提交前没有清理，评审也没注意这类小改动。没有工具在提交时拦截。这一点先确认清楚，后面就不用反复试。
grep -rn 'console\.log\|debugger' src/ --include='*.ts' | wc -l grep -rn 'TODO' src/ | grep -v 'TODO(\w*-[0-9]*)'
围绕「调试代码入库」排查时，命令行跑一遍比在面板里点十次有用，面板会替你做掉不少隐式操作。先做最小复现，能稳定跑出来的问题，排查成本会低一个数量级。
别只看报错的最后一行，往上看几行，真正的起因通常在上面。同类问题如果隔一段时间又出现，多半是某个定时任务或重启流程把改动冲掉了。
把这次用到的命令存进笔记，比记住结论有用，换个环境还能照着走。
处理上按这个顺序：加 pre-commit 钩子拦截 console.log 和 debugger；TODO 必须带 issue 编号 否则报错；评审清单里加一条检查调试残留；发布前跑一次全量 grep 确认干净。
结果对不对很好判断，提交时 console.log 被钩子拦下，发布包里 grep 不到调试语句和裸 TODO。