Code Review 应该看什么？只看风格是不是太浅
很多团队把 Code Review 做成了“挑格式、挑命名”的检查，但这样很容易错过真正影响质量的问题。除了风格之外，评审时通常还需要关注功能是否正确、边界条件是否被覆盖、异常处理是否合理、代码是否容易维护、是否存在性能隐患，以及改动会不会影响现有逻辑。
Code Review 的重点不只是风格
代码风格只是基础项，更有价值的检查点是业务正确性、边界处理、可读性、可维护性和潜在风险。评审时可以先看这个改动解决了什么问题，再判断实现是否符合预期、是否有遗漏场景、是否引入回归风险。这样做能让 Code Review 从“挑毛病”变成“提前发现问题、提升整体质量”。
有些代码排版整齐、命名也清晰，看上去没有什么问题，但实际可能隐藏着逻辑漏洞或设计缺陷。单纯因为“看起来顺眼”就放过评审，是否会让问题在上线后才暴露？
规范外观不等于实现没问题
有必要继续深入。表面规范只能说明代码容易阅读，不代表实现正确。评审时应该继续确认业务逻辑是否完整、数据流是否清楚、接口契约是否稳定、异常场景是否处理到位。很多线上问题并不是来自风格，而是来自业务理解偏差或实现细节遗漏。
有些实现一次能跑通，但过一段时间别人接手时很难修改。除了可读性，评审时还能从哪些角度判断这段代码未来是否容易维护、扩展和排错？
可维护性要看结构、职责和扩展成本
判断可维护性时，可以关注几个信号：模块职责是否单一、函数是否过长、条件分支是否过多、重复逻辑是否明显、依赖关系是否复杂。还可以看这次改动以后，后续新增需求是否需要大范围修改。能把职责拆清楚、把变化点隔离开的代码，通常更适合长期维护。
不少团队的评审内容会慢慢变成固定模板，比如只检查缩进、空格、命名，而对业务风险、性能问题、异常分支几乎不提。有没有更有效的评审思路，能让大家把注意力放在真正重要的地方？
用检查清单把注意力拉回核心问题
可以给 Code Review 制定一份简洁的检查清单，把关注点从“表层问题”转向“真实风险”。比如：需求是否实现完整、边界条件是否覆盖、错误处理是否可靠、性能是否可接受、是否影响现有模块、测试是否充分。这样评审会更稳定，也能减少大家把时间花在低价值细节上的情况。