代码审查优先级：为什么安全先于可维护性

代码审查里最容易跑偏的时刻，是大家围着命名、抽象和文件拆分讨论得很热闹，却没人追问：这段改动会不会让不该访问的人拿到数据，或者让普通账号完成本不该完成的操作？

可维护性当然重要。混乱的结构会拖慢后续开发，重复逻辑会让修复变得昂贵，难懂的代码也会让团队逐渐失去修改它的勇气。但这些问题通常还有回旋余地：可以重构、补测试、逐步统一约定。安全问题的性质不同，它可能在一次合并后立刻越过权限边界，影响真实用户和真实数据，后果往往不等人。

所以，审查顺序不该由“哪里最显眼”决定，而应由“哪里造成的损害最大”决定。先看身份从哪里来，权限判断是否覆盖完整调用链，资源归属有没有被核验；再看外部输入、输出内容、异常信息和敏感配置。确认这些边界没有明显缺口后，才值得把注意力放到空值、重复请求、失败路径和状态变化上。

这并不意味着安全问题可以靠几条固定规则扫出来。一个权限判断写在代码里，不代表它放在了正确的位置；前端不显示某个按钮，也不等于接口无法被调用。审查者需要理解功能目标和调用关系，判断“已登录”是否真的等于“有权操作当前资源”。这里最需要的不是漂亮的评语，而是对业务后果的追问。

AI 可以帮忙扩大检查范围，提示遗漏的路径或边界情况，但它给出的风险仍需人工核验。真正有价值的审查意见，应当能说明问题出现的位置、触发条件和可能影响，而不是留下一个模糊的“建议优化”。

安全优先也不是贬低可维护性，而是在有限注意力里先守住不能失守的边界。结构问题可以排期，命名争议可以讨论；一旦权限、数据访问或输入处理存在缺口，合并之前就应先把它说清楚、验证清楚。代码是否优雅值得讨论，但它首先得是安全的。