VS Code 本身不提供内置代码审查功能，需依赖 GitHub PR 插件、GitLens 等工具实现：GitHub 插件支持 PR 查看、diff 评论与建议修改；GitLens 提供行级作者/提交信息悬停、历史对比；Settings Sync 和 Workspace Trust 可统一配置并保障安全。
VS Code 本身不提供内置的代码审查（Code Review）流程管理功能，它依赖插件和外部服务协同完成——真正起作用的是 GitHub Pull Requests and Issues、CodeStream 或与 GitLens 配合的本地差异分析能力。
如何用 GitHub PR 插件在 VS Code 里直接审阅 PR
这是目前最接近“原生体验”的协作审查方式，前提是你的代码托管在 GitHub（支持 GitHub Enterprise）。
- 安装官方插件
GitHub Pull Requests and Issues，登录 GitHub 账号后自动同步仓库权限 - 打开任意克隆好的仓库，在左侧活动栏点击
PRs图标，即可看到当前分支关联的 PR 列表 - 点击一个 PR 后，VS Code 会拉取其变更文件树，双击文件进入 diff 视图——这里支持行级评论、@ 提及、表情反应，且所有操作实时同步到 GitHub
- 注意：评论提交后不会自动推送 commit，只是 GitHub 上的 review comment；若需建议修改，应使用
Suggest change功能生成代码块，对方可一键采纳
为什么 GitLens 是本地代码审查不可少的辅助工具
当团队没有统一 PR 流程，或你需要快速理解某段代码“谁改的、为什么改、改过几次”，GitLens 提供的上下文比任何注释都可靠。
- 启用后，编辑器右键菜单多出
GitLens: Compare With Previous Revision等选项，能快速对比任意两个 commit 的差异 - 按住
Alt（Windows/Linux）或Option（macOS）悬停在代码行上，会显示该行最近一次修改的 author、commit message 和时间 -
Git Timeline视图可按文件或作者筛选历史变更，适合在交接或排查时快速定位责任边界 - ⚠️ 坑点：默认不追踪未暂存（unstaged）变更，如需对比工作区与暂存区，得手动右键选择
Compare With Staged
用 Settings Sync + Workspace Trust 避免协作中的配置冲突
多人共用同一仓库时，格式化规则、ESLint 配置、TODO 高亮等设置不一致，会让 code review 变成风格战争。
- 推荐用 VS Code 内置的
Settings Sync（需登录 Microsoft 账户），把关键设置如editor.formatOnSave、eslint.validate同步到团队成员账户 - 项目根目录放
.vscode/settings.json，显式声明"editor.codeActionsOnSave": { "source.fixAll.eslint": true }，比口头约定更可靠 - 开启
Workspace Trust后，VS Code 会阻止未信任工作区自动运行脚本（如 pre-commit hook），防止恶意配置被带入协作环境——但也要记得在首次打开他人 PR 分支时手动点击Trust Workspace
真正的代码审查难点不在工具链，而在于 diff 是否聚焦、评论是否可执行、上下文是否随手可得。VS Code 能做到的，是把原本要切窗口、查日志、翻 commit 的动作，压缩进一次右键、一次悬停、一次点击里——但前提是选对插件、配对配置、并且团队愿意统一基础规则。
