GitLens、GitHub PR 插件、ESLint+Prettier、cSpell 四类工具协同提升代码审查效能：GitLens 通过 blame 追溯修改源头，PR 插件打通本地与远程审查上下文，ESLint+Prettier 自动化规范代码质量，cSpell 防范拼写引发的语义歧义。
GitLens 显示每行最后修改人，比“看 diff”更早发现问题
你不是在 review 一次提交，而是在理解一段代码的演化路径。如果某行逻辑突然变复杂，但 blame 显示是三个月前由 @alice 提交的、当时只改了一个字段，那这次变更很可能破坏了原有假设。GitLens 的 Blame Annotated Line 功能就干这个：右键某行 → 选它，立刻跳转到对应 commit，还能看到当时的 commit message 和 diff 上下文。
- 安装后默认启用，无需额外配置；若没反应，检查右下角是否提示
Workspace Trust被禁用（未信任工作区会停用 GitLens） - 悬停行号时出现的 blame 浮层里，点击作者名可过滤该人所有修改，适合快速定位责任链
- 配合 Timeline 视图（右键文件 →
Git: Timeline），能对比两个历史版本，避免把“本来就这样”的逻辑误判为 bug
GitHub Pull Requests and Issues 插件让本地审查直连远程 PR
不用切网页，PR 的全部上下文就在编辑器里：文件列表、diff、评论输入框、审批按钮，甚至能直接运行 git pull 拉取分支。关键不是“能看”，而是“能验证”——点开一个被标记为 console.log 的行，右键选 Find All References，立刻确认是否遗漏调用处。
- 安装后需登录 GitHub 账号（状态栏右下角点击 Copilot 图标旁的 GitHub 图标）
- 打开 PR 后，左侧文件树中灰色图标表示未变更文件，绿色/红色才是 diff 区域
- 在某行右键 →
Add comment，支持@username提及，提交后自动同步到 GitHub，对方收到邮件通知 - 若 PR 关联了 CI 状态，插件会在文件树顶部显示 ✅ / ❌，点开可跳转到 Action 日志
ESLint + Prettier 在保存时自动修复，省掉格式争议
人工 review 时争论“缩进用 2 还是 4”毫无意义。ESLint 把规则变成诊断项，Prettier 把格式变成确定性输出，两者配合后，editor.formatOnSave 和 editor.codeActionsOnSave 一开，保存即修正。
- 确保项目根目录有
.eslintrc.js或.prettierrc，否则 VSCode 会 fallback 到全局配置，导致团队间行为不一致 - 推荐设置：
"eslint.enable": true、"editor.formatOnSave": true、"editor.defaultFormatter": "esbenp.prettier-vscode" - 注意冲突点：Prettier 会覆盖 ESLint 的格式类规则（如
indent），所以必须禁用 ESLint 中重复的格式规则，否则保存时反复横跳
cSpell 检查变量名和注释拼写，堵住低级语义漏洞
recieve 和 receive 在语法上完全合法，但会让后续维护者困惑；AuthZ 被标红？那是插件不认识你的团队术语——得加进 .cspell.json 的 words 数组。这类问题不该占用人工 review 时间，应该在敲完第一行注释时就被标出来。
- 安装后默认扫描
comments、strings、identifiers，但不会检查import路径或 JSON key - 中英文混合项目必须设
"cSpell.language": "en,zh"，否则中文注释全报错 - 自定义词典要放项目根目录，且
"cSpell.allowCompoundWords": true可避免把userInput拆成user和Input分别标红
真正卡住审查节奏的，从来不是“看不到问题”，而是“不确定这个问题是不是历史遗留”。GitLens 的 blame 数据、GitHub PR 插件的上下文链接、ESLint 的实时诊断线，三者叠加才能让一句“这里建议重构成函数”背后有 commit、有规则、有依据——而不是凭感觉。
