代码审计（Code Audit）说得通俗一点，就是请别人——或者自己——带着怀疑的目光，把写好的代码从头到尾读一遍。不是为了找茬，是为了找那些"看起来能跑，但迟早出事"的地方。

这件事听起来简单，实际做起来有几点容易被忽视。

1. 不要假设 "之前审核过了"

代码是活的。今天加一个功能，明天修一个 bug，后天改个配置项——每一次变更都可能在不经意间引入新的问题。所以严格的团队会要求 每次合并请求都必须经过审计，而不只是"上线前审一次"。

2. 注意 "死代码"

功能迭代过程中，旧的工具函数、废弃的配置常量、不再被调用的辅助方法，很容易被遗忘在脚本角落。它们不报错、不影响编译、不触发告警——但它们增加了单次阅读的心理负担，让真正的问题更难被发现。

这次审计中就清理了一个 18 行的死函数，虽然它啥也没破坏，但删掉之后代码结构清爽了不少。

3. 边界情况比主流程更容易出问题

主流程（发布文章、上传图片）因为经常跑，有 Bug 也早暴露了。真正容易藏雷的是那些 "用户不会常规触发"的分支：

• 非交互环境下按 Y 确认删除（input 抛 EOFError → 直接崩溃）
• 仅修改封面不修改正文的场景（has_change 没覆盖到 cover 字段）
• 超 100 篇已删除文章的回收站（分页可能漏）

这些场景可能几个月才触发一次，但一旦触发就是事故。

4. 审计要做，但也要有个度

完全无 Bug 的代码不存在。审计的价值不在于"消灭所有问题"，而在于 砍掉风险等级最高的那些，剩下的低风险项如果影响很小、触发概率也小，可以标注后放行，不必每行都追求完美。

5. 最容易被忽略的一件事：记录审计结论

审计过程中有一些代码看起来可疑，但经过分析确认没问题。如果只记在脑子里，下次审计又会被标记成"可疑"——浪费时间。把结论写进代码注释或变更日志，是性价比最高的做法。

这次对线上脚本做了完整审计，前后发现并修复了 10 个问题，脚本从 2500 行精简到约 2480 行，功能完整度不变。一次值得的健康检查。