要做好前端代码审查（Code Review），核心在于建立一套既保证代码质量，又不挫伤团队士气的流程。它不仅仅是找Bug，更是知识共享和统一规范的过程。
下面从审查的维度、流程、沟通技巧和自动化辅助四个方面来具体说明。
一、审查什么？—— 六大核心维度
审查时按优先级从高到低检查：
-
功能与逻辑正确性
- 代码是否真的解决了需求？边界条件（空数据、极端值）处理了吗？
- 异步操作（Promise、async/await）的错误捕获是否完善？
- 是否存在常见的逻辑错误，如
== vs ===，变量提升问题？
-
性能与体验
- 渲染效率：是否存在不必要的重复渲染（React的
useCallback、useMemo，Vue的computed使用是否恰当）？
- 资源加载：图片是否懒加载？组件是否按需导入（动态import）？Bundle体积是否过大？
- 交互流畅度：高频事件（滚动、输入）是否有防抖/节流？
-
可维护性与可读性
- 命名：变量、函数、组件名是否准确表达意图（如
getUserData 优于 getData）？
- 复杂度：函数是否过长（建议<50行）？嵌套层级是否过深？是否有违反“单一职责”原则的代码？
- 注释：业务逻辑复杂处是否有注释？不要注释“做了什么”，要注释“为什么这么做”。
-
安全性（前端特有）
- 是否存在XSS漏洞（直接使用
innerHTML、dangerouslySetInnerHTML）？
- 敏感信息（API密钥、Token）是否硬编码在前端？
- 用户输入是否经过验证和转义？
-
可访问性（A11y）
- 语义化HTML是否使用得当（
button vs div模拟按钮）？
- 图片是否有
alt属性？键盘是否可操作焦点？
-
规范与风格
- 缩进、引号、分号等风格问题应完全交由Prettier等工具自动处理，人工只关注工具无法判断的逻辑。
二、怎么审查？—— 高效的五步流程
-
审查者准备
- 先理解PR的背景（需求链接、设计图），再读代码，不要只看代码改动。
- 建议从整体架构开始看（文件结构、组件拆分），再深入到具体实现。
-
小步快跑
- 单个PR最好控制在200-400行以内。超过1000行的PR，审查效果会急剧下降，应要求作者拆分提交。
-
区分“必须改”与“建议改”
- 必须改：逻辑错误、安全漏洞、严重性能问题。
- 建议改：更好的命名方式、更优雅的实现、可选的性能优化。给建议时用“你觉得...怎么样？”。
-
本地验证（关键步骤）
- 对于复杂逻辑或UI改动，一定要拉分支到本地运行测试。只看diff很难发现样式错位或交互bug。
-
最终确认
- 所有“必须改”的问题解决后，再批准合并。不要累积“技术债”。
三、沟通原则—— 对代码不对人
不良的评审很容易引发对立。注意以下表达方式：
- ❌ 差：“你这里写错了。” “你怎么不用XXX设计模式？”
- ✅ 好：“这个变量名
data有点模糊，改成 userProfile 会不会更清晰？” “考虑到后续可能需要扩展，这里用策略模式是不是更好？可以一起讨论下。”
核心建议：对于可读性、风格类问题，优先通过ESLint/Prettier等规则固化，不要让人工反复争论。
四、善用工具—— 自动化做脏活累活
在人工审查前，先用自动化工具过滤掉低级问题：
| 工具 |
作用 |
| ESLint + Prettier |
自动化检查语法错误、风格统一 |
| TypeScript |
强类型系统能在编译时避免大量错误 |
| Husky + lint-staged |
Git提交前自动检查和格式化代码 |
| SonarJS |
扫描代码坏味道、重复代码、潜在Bug |
| Chrome Lighthouse |
审查可访问性、性能、SEO建议 |
五、建立团队共识
- 制定并文档化规范：以项目根目录的
.eslintrc、.prettierrc和一份 CONTRIBUTING.md 文档为准。
- 定期复盘：每月拿出半小时，回顾过去一个月CR中反复出现的问题，更新规范。
- 新手正向引导：对刚入职同事的PR，多给鼓励式建议，少用“必须改”。
一个高效的审查清单（可直接用于团队）
- 代码正确实现了需求，并考虑了边界情况？
- 是否存在硬编码、魔法数字或重复代码？
- 是否有潜在的性能问题（频繁渲染、大列表未虚拟化）？
- 是否处理了所有可能的错误（网络请求、用户输入）？
- 组件拆分是否合理？是否太胖或太薄？
- 是否引入了无用的依赖或文件？
- 本地运行后，UI在不同分辨率下是否正常？
最后，记住一个好公式：
好的代码审查 = 自动化工具（守底线） + 合理的流程（保效率） + 共情的沟通（促协作）
