🔍 Code Review 最佳实践 · 全面指南(可以裸泳但没必要)

✨ 为什么这篇值得看？

很多 code review 就是扯蛋哈哈不过这个东西其实也可以不需要但不好维护和统一标准✅

很多团队 Code Review 流于形式、走过场，甚至变成"拍脑袋式指指点点"。

本篇不是讲"要认真、要负责任"这类空话，而是：

✅ 从实际项目中挑出最容易出错的写法

✅ 展示"错误示例 + 修改建议 + 解释理由"

✅ 给出「可复用的 Review 检查清单」

✅ 提供给初级同学/带团队的你，一套系统落地方案

📘 结构总览

不要只看"能不能跑"，而要审"写得好不好"
核心维度一览：逻辑健壮性、性能、可读性、扩展性、安全性、团队协作
真实项目中的 Code Review 场景案例
如何制定团队的 Review 流程和标准
自动化辅助：lint、pre-commit、CI、PR 模板

🧱 1. Code Review 核心维度检查清单

维度	关键点	常见问题
✅ 功能正确性	逻辑、边界、异常	判断遗漏、空值未处理
🚀 性能优化	是否有多余渲染/计算	不必要的 setState/useEffect
🧠 可读性	命名、注释、函数长度	魔法数、逻辑嵌套多层
🔧 可维护性	是否易扩展、易测试	写死常量、缺乏抽象
🔐 安全性	是否防止 XSS/注入	v-html、innerHTML
🤝 团队协作	是否遵循规范	命名不一致、代码风格跳脱

💣 2. 实战错误案例：边看边改

案例 1：功能正确性缺失（空值判断）

❌ 错误写法：

js 复制代码

const userName = user.name.toUpperCase()

在某些 API 请求失败或字段不返回时会直接报错。

✅ 推荐写法：

js 复制代码

const userName = user?.name?.toUpperCase?.() || '未知用户'

或者：

ts 复制代码

if (user?.name) {
  return user.name.toUpperCase()
}
return '未知用户'

案例 2：性能问题（useEffect 无依赖、setState 重复）

❌ 反面写法：

tsx 复制代码

useEffect(() => {
  fetchData()
}, [])

但 fetchData 是一个带闭包引用的函数，每次 render 都变。

✅ 改进方法：

tsx 复制代码

const fetchData = useCallback(() => {
  // do something
}, [userId])

useEffect(() => {
  fetchData()
}, [fetchData])

或直接用 react-query/swr 解耦副作用。

案例 3：代码可读性差（魔法数、if 嵌套）

❌ 看不懂的代码：

ts 复制代码

if (a === 2 && b === 3 && c === 4) {
  doSomething()
}

✅ 更可读的写法：

ts 复制代码

const isValid = a === AGE_LIMIT && b === LEVEL && c === TYPE_CODE
if (isValid) {
  doSomething()
}

案例 4：抽象缺失，难以维护

❌ 写死：

ts 复制代码

if (status === 'active') {
  return '启用中'
}

✅ 推荐：

ts 复制代码

const STATUS_MAP = {
  active: '启用中',
  inactive: '停用',
  pending: '待审核',
}
return STATUS_MAP[status] || '未知'

案例 5：命名不一致导致理解成本高

❌ 变量名混乱：

ts 复制代码

const u = getUser()
const n = u?.n

✅ 一致命名，提升可读性：

ts 复制代码

const userInfo = getUser()
const userName = userInfo?.name

案例 6：安全问题（XSS 注入风险）

❌ 危险写法：

html 复制代码

<div v-html="item.content"></div>

✅ 使用内容白名单清洗，或 markdown 渲染库：

html 复制代码

<div v-html="sanitize(item.content)"></div>

ts 复制代码

import DOMPurify from 'dompurify'
const safeHtml = DOMPurify.sanitize(html)

案例 7：团队风格不统一

❌ 有人写箭头函数，有人写匿名，有人用 var...

✅ 使用 ESLint + Prettier 强制风格一致：

bash 复制代码

# 安装
pnpm i -D eslint prettier eslint-config-prettier eslint-plugin-prettier

配置 .eslintrc.js：

js 复制代码

extends: ['plugin:vue/vue3-recommended', 'prettier'],
plugins: ['prettier'],
rules: {
  'prettier/prettier': 'error',
  'no-var': 'error',
  'prefer-const': 'error',
}

✅ 3. Code Review Checklist（代码审核清单）

你可以将以下内容作为团队的 PR 模板，或者作为 review checklist 工具：

md 复制代码

### 🧠 Code Review Checklist

- [ ] 功能是否正确？逻辑、边界条件考虑完整了吗？
- [ ] 代码是否易读、变量命名是否清晰？
- [ ] 是否有重复代码、是否可抽象？
- [ ] 性能方面是否有优化空间（缓存、副作用、复杂渲染）？
- [ ] 安全问题有没有？（XSS、数据注入）
- [ ] 是否符合团队 ESLint/Prettier 规范？
- [ ] 是否写了注释/文档/单测？

🤖 4. 自动化辅助 Review 的配置推荐

💡 ESLint + Prettier：风格统一、自动格式化
🔒 commitlint + husky：提交信息规范，避免 Git 混乱
✅ CI：自动跑测试、防止未通过代码合并
📄 PR 模板：明确审核项

.github/pull_request_template.md 示例：

md 复制代码

### 本次改动内容：
- 解决了 __ 问题
- 优化了 __ 模块

### 检查点：
- [ ] 本地测试通过
- [ ] 已覆盖边界条件
- [ ] ESLint 无报错

🔚 总结：Code Review ≠ 挑毛病，而是一起变强

好的 Code Review 是团队进步的放大器，它可以：

让新人成长得更快
让系统变得更稳定
让"技术债"更少
让协作更高效