Code Review 最怕变成格式检查，也怕变成主观审美比赛。真正有价值的 Review，核心不是证明谁写得更好，而是提前发现风险。
我通常会先看行为，再看结构，最后看风格。行为层面最重要：这个改动是否真的满足需求？有没有破坏已有路径？异常情况怎么处理？边界输入会不会出问题？如果这些问题没看清，纠结变量名往往意义不大。
结构层面关注的是后续维护成本。比如这个逻辑是不是放在了合适的位置，是否把领域规则散落到了多个文件，是否引入了难以测试的全局状态。Review 时不一定要追求完美抽象，但要避免让下一次修改变得明显更难。
风格层面也重要，但应该尽量自动化。格式、排序、简单 lint 规则交给工具，不要让人肉 Review 消耗在这些地方。人的注意力应该留给工具不擅长判断的部分：业务语义、风险、可读性和长期演进。
一个好的 Review 评论应该具体、可操作。比如“这里看起来不太好”没有太多帮助；“这个分支里 userId 为空时会跳过权限校验，是否需要返回 401？”就能推动问题被解决。
Code Review 的目标不是把代码改成自己的写法，而是让这次变更更可靠。保持这个目标，讨论会少很多情绪，多很多工程质量。