VSCode 本身不内置代码审查功能，但可通过 GitLens 追溯变更、ESLint+Prettier 自动拦截基础问题、GitHub/ReviewNB 网页端完成异步批注，形成高效审查工作流。
VSCode 本身不内置代码审查（code review）功能，但可以通过组合扩展、Git 集成和轻量级配置，快速搭建适合个人或小团队的审查工作流——关键不是装一堆插件，而是明确「谁在什么环节看什么」。
用 GitLens 看清每一行是谁改的、为什么改
代码审查的前提是能快速追溯变更上下文。GitLens 是目前 VSCode 中最稳定、低侵入的 Git 增强工具，它把 blame、commit history、文件差异直接嵌入编辑器侧边和行内。
- 安装后默认启用行内 blame（hover 行号可见作者/提交信息），无需额外配置
- 按
Ctrl+Alt+H（Windows/Linux）或Cmd+Option+H（macOS）可呼出当前文件的 commit history 面板 - 右键某一行 →
GitLens: Compare Line with Previous Revision，立刻对比该行上一次修改前后的差异，比只看 diff 更聚焦 - 避免启用
GitLens: Advanced Syntax Highlighting，它会干扰部分语言高亮，尤其在 TypeScript + JSX 混合文件中容易误标语法错误
用 ESLint + Prettier 自动拦截基础问题
人工审查不该花时间在缩进、分号、未使用变量这类问题上。让工具在保存时就报错或自动修复，审查者才能专注逻辑、边界、接口设计等真正需要人判断的部分。
- 确保项目根目录有
.eslintrc.cjs（或.eslintrc.json），且已安装对应解析器（如@typescript-eslint/parser） - 在 VSCode 设置中开启
editor.codeActionsOnSave，并指定仅对 ESLint 启用自动修复："editor.codeActionsOnSave": { "source.fixAll.eslint": true } -
Prettier不要设为默认格式化工具；应通过eslint-config-prettier关闭 ESLint 中与 Prettier 冲突的规则，再由 ESLint 统一执行格式化 —— 否则多工具打架会导致保存时反复重排、光标跳动 - 若用 TypeScript，务必检查
eslint-plugin-react或@typescript-eslint/eslint-plugin版本是否匹配 TS 版本，否则会出现Definition for rule 'xxx' was not found报错
用 ReviewNB 或 GitHub PR 界面做异步批注（不依赖 VSCode 插件）
VSCode 的「本地审查」只是前半程。真正的代码审查发生在 Pull Request 阶段，而 VSCode 插件做 PR 批注容易同步失败、丢失上下文、不支持 @mention 和 resolved 状态管理。
- 放弃
GitHub Pull Requests and Issues插件做深度审查：它适合快速查看 PR 列表，但行级评论体验远不如网页端，尤其涉及多文件跳转、diff 折叠、图片粘贴时卡顿明显 - 推荐流程：本地用
GitLens+ESLint完成自检 → 推送分支 → 在reviewnb.com（适合 Jupyter/数据类项目）或 GitHub PR 页面发起审查 → 使用原生网页批注 +Resolve conversation跟踪闭环 - 如果必须在 VSCode 内打开 PR，可用
Ctrl+Shift+P→ 输入GitHub: Open Pull Request直接跳转到对应网页，不强行在编辑器里完成全部动作
最常被忽略的一点：审查工作流的有效性不取决于工具链多完整，而在于「谁在哪个环节停止推送」。比如 ESLint 报 error 级别问题时，CI 必须拒绝合并；Git 提交信息没过 conventional commits 校验，husky 就该拦在本地。工具只是放大人为约定的执行力度，而不是替代它。
