在代码行上加审查意见标记需安装GitHub官方插件并登录，在PR diff视图中右键目标行选Add Comment输入Markdown评论；支持Start Review批量提交，但仅限已打开的PR文件，未登录时选项置灰。
怎么在代码行上加审查意见标记
VSCode 本身不提供原生的「审查意见标记」功能，必须靠插件实现。最直接、最常用的是 GitHub Pull Requests and Issues 插件——它不是“标记”，而是把评论锚定到具体行，并同步到 GitHub PR 上。
安装后，在 PR 的 diff 视图中，把光标停在某行，右键 → Add Comment 即可输入意见。注意：这个操作必须在已打开的 PR 文件里进行，不能在本地未提交的文件中随意标记。
- 未登录 GitHub 账号时，
Add Comment选项是灰色不可用的 - 评论内容支持 Markdown，但不支持插入图片或语音（多模态批注需手动开启实验配置，且目前稳定度低）
- 如果想临时存多条意见再统一发，要先右键 →
Start Review，否则每条都是立即提交
Bookmarks 插件能当审查标记用吗
可以，但不是为审查设计的。它本质是个人导航工具，适合快速跳转，不适合协作场景下的意见追踪。
比如你在 review 时发现三处需要改的逻辑点，用 Ctrl+Alt+K 打三个书签，颜色区分（红色=待修复、黄色=待确认），确实比写文档快。但问题在于：这些标记只存在你本地，不会同步给同事，也不能关联到某次提交或 PR。
- 书签没有上下文描述，别人看不到你为什么标这里
- 无法导出/分享标记列表，也不支持 @ 提及或状态更新
- 如果项目用了
GitLens，它的Show Commit in Timeline更适合追溯某行为何这么写，比书签更有审查价值
通义灵码和 SonarLint 的审查标记有什么区别
两者都生成「标记」，但来源和用途完全不同：通义灵码是 AI 驱动的实时建议，SonarLint 是基于规则的静态分析警告。
tongyi.codeReview.enable 开启后，你在写 v-for 时，编辑器会自动在行尾标出「缺少 :key」；而 SonarLint 在你声明一个未使用的变量时，会在该变量下划波浪线并提示「Unused variable」。
- 通义灵码的标记可配置
tongyi.codeReview.level控制严重等级（suggestion/warning/error），但不支持自定义规则语法 - SonarLint 的标记对应真实规则 ID（如
java:S1192），点击可跳转到规则说明页，适合团队统一质量门禁 - 两者都依赖语言服务器，但 SonarLint 对 C++/Java 支持更稳，通义灵码目前强项在 Vue/TS/JS
为什么 GitLens 的 Blame 标注不算审查意见标记
因为它不承载「意见」，只呈现「归属」。GitLens 在行号旁显示 abc1234 · @alice · 2 days ago，这只是告诉你这行是谁、什么时候、基于哪个 commit 写的，不是评价对错。
但它对审查极关键：当你看到一行可疑代码，第一反应不该是“这写得不对”，而是“谁写的？当时为什么这么改？”。Blame 就是回答后两个问题的最快路径。
- 刚 rebase 过的分支，Blame 默认显示新 commit hash，容易误判作者——此时右键文件 →
GitLens: Toggle Blame for Current Line (Based on Original Commit)可切回原始归属 - Blame 不会高亮风险代码，但配合
SonarLint或ESLint，就能把「谁写的」和「哪里有问题」叠加起来看 - 它不支持添加文字评论，但右键 →
GitLens: Show Commit in Timeline可拉出该行完整演进链，这才是审查时真正需要的上下文
实际做审查时，真正的难点不在「标哪里」，而在「标完之后怎么推动闭环」。比如一条 Add Comment 发出去，没人回复；一个 SonarLint 警告被 // eslint-disable-next-line 绕过；甚至你本地的 Bookmarks 标记好了，切分支就全丢了——这些都不是插件能解决的，得靠流程卡点和团队约定。
