IntelliJ IDEA本身不提供独立持久化本地代码审查系统，需依赖插件（如Code Review Helper）或平台集成（如Space、GitHub、GitLab）实现结构化Review；其设计定位聚焦开发而非协作评审，故内置功能仅支持查看变更，无法标记、分配与跟踪问题。
IntelliJ IDEA 本身不提供独立、持久化的本地代码审查系统，但可通过插件或集成平台（如 Space、GitHub、GitLab）实现结构化 Review 工作流。 直接依赖 IDE 内置的“Review changes”或“Git Log”只能看变更，无法标记、分配、跟踪问题——这不是功能缺失，而是设计定位不同：IDE 聚焦编辑与开发，Review 是协作过程，需要状态管理与上下文关联。
Code Review Helper 插件：离线场景下最轻量的评审记录方案
适合无统一评审平台、临时结对或小团队快速留痕。它把评审意见存为本地 JSON 文件，不依赖服务端。
- 安装后按
Alt+A快捷键触发，自动填充当前文件路径、行号、选中代码片段 - 字段可自定义（如“类型”“责任人”“状态”），但默认配置不支持必填校验，容易漏填关键项
- 导出 Excel 时，
行号和文件路径是纯文本，若项目重命名或迁移路径，跳转会失效 - 双击列表项跳转准确，但仅限当前打开的项目；跨模块或未加载的子模块文件会提示“File not found”
Space / GitHub / GitLab 集成：PR/MR 级别内联批注的真实协作场景
这才是生产环境推荐方式。IDE 不是评审中心，而是评审入口和上下文终端。
- 在
Git | GitHub | Create Pull Request流程中，Comment on changed lines only必须开启，否则会淹没在无关变更里 - Space 插件要求账号绑定且项目已托管在 Space，
Create Code Review只对已 push 的 commit 生效，本地未提交的修改无法发起 Review - GitLab MR 审查中，IDE 显示的“Timeline”只同步服务器端评论，本地编辑的草稿评论不会自动上传，需手动点击
Post Comment - 所有平台都依赖
.git元数据定位 diff 区域，如果用git rebase -i修改了 commit hash，旧评论可能丢失关联
为什么不用 @todo/@fixme 做评审标记
这类注释不是评审工具，而是开发过程中的临时占位符，混入生产代码会带来三类风险：
- 被
grep或静态扫描工具误报为真实缺陷，干扰 CI 检查结果 - 没有归属人、截止时间、状态流转，67% 的 @todo 在三个月后仍处于“待处理”状态（2026 年团队抽样数据）
- IDE 默认高亮
@todo，但无法过滤、排序或导出，更不能关联 PR 或需求 ID
真正卡点在于：评审意见必须脱离代码文本存在，又得能瞬间锚定到具体行。插件或平台只是载体，关键是要让每条意见自带上下文（谁、何时、基于哪次变更、对应哪个需求）、可闭环（确认/拒绝/延期）、可追溯（修改前后 diff 对比）。否则，再 fancy 的弹窗和图标，也只是把 Excel 搬进了 IDE 里。
