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

✨ 为什么这篇值得看？

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

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

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

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

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

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

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

---

📘 结构总览

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

---

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

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

---

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

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

❌ 错误写法：

const userName = user.name.toUpperCase()

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

✅ 推荐写法：

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

或者：

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

---

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

❌ 反面写法：

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

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

✅ 改进方法：

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

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

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

---

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

❌ 看不懂的代码：

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

✅ 更可读的写法：

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

---

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

❌ 写死：

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

✅ 推荐：

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

---

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

❌ 变量名混乱：

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

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

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

---

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

❌ 危险写法：

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

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

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

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

---

案例 7：团队风格不统一

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

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

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

配置 .eslintrc.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 工具：

### 🧠 Code Review Checklist

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

---

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

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

.github/pull_request_template.md 示例：

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

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

---

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

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

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

---