GitLens内联blame不显示的三大硬性条件是：文件必须已提交、工作区须识别为有效Git仓库（状态栏显示分支名）、gitlens.blame.line.enabled必须设为true；monorepo中需手动指定顶层.git目录。
GitLens 不是“能用就行”的插件，它在企业级代码审计中真正起效的前提，是你关掉了默认的“友好模式”，启用了带上下文约束的追溯策略。
内联 blame 为什么没显示？检查三个硬性条件
很多团队装完 GitLens 就以为万事大备，结果鼠标悬停没反应、右键菜单空空如也——这不是插件故障，而是 GitLens 拒绝在不安全或无意义的上下文中提供信息。
- 文件必须已提交（
git status中不能是untracked或仅暂存未提交） - VS Code 当前工作区必须识别为有效 Git 仓库（底部状态栏应显示分支名，如
main；若显示No source control providers，说明工作区根目录下没有.git） -
gitlens.blame.line.enabled必须为true（不是靠“启用插件”自动生效，需显式开启；可在设置中搜索该配置项确认）
特别注意：在 monorepo 中打开子包目录（如 packages/utils），但 Git 仓库根在上层时，VS Code 可能无法自动识别。此时需手动在命令面板执行 Git: Open Repository 并选择顶层 .git 目录。
对比两个版本时 diff 为空？关键看 commit 范围是否合法
GitLens: Compare with Previous Revision 看似简单，实际依赖 Git 的精确路径解析。选中代码后对比失败，90% 是因为：
- 当前文件是首次提交后的新增文件（
HEAD~1不存在该路径，Git 无法定位上一版内容） - 你选中的代码块，在上一个 commit 中根本不存在（例如刚重写了整个函数，旧版是另一套逻辑）
- 使用了
rebase或filter-branch后，原始 commit hash 已失效，GitLens 时间轴视图可能仍显示旧记录，但底层git show命令已查不到对应快照
实操建议：遇到空 diff，先退一步，用命令行验证基础可用性：git log -n 3 --oneline -- src/utils/dateFormatter.ts，确保至少有 2 条历史记录；再尝试 GitLens: Compare with Revision... 手动指定 HEAD~2 而非依赖自动推导。
多人协作场景下作者标注失真？合并提交和变基是主因
当你看到某行代码标注为 @alice 2024-03-15，但 Alice 声称自己从未碰过这个文件——大概率是她提交的 PR 被 merge --squash 或 rebase 后合入，导致原始 author 信息被覆盖为 committer（通常是合并者）。
- GitLens 默认显示的是
committer，而非原始author；想还原真实作者，需在设置中启用gitlens.advanced.git.authorInBlame（设为true） - 启用后，内联 blame 会优先展示
author字段，但前提是该 commit 未被重写；如果已 squash/rebase，原始 author 信息实际已从历史中丢失 - 企业级审计要求可追溯性时，必须约定 PR 合并策略：禁用
squash and merge，强制使用create a merge commit，否则 GitLens 无法还原真实责任人
审计敏感逻辑时，别只看最后一改
线上支付校验逻辑出错，blame 显示是张三上周加的 if (user.country === 'CN') ——但这只是表象。企业级回溯必须穿透“修改链”：
- 右键该行 →
GitLens: Open File History→ 在时间轴中找到张三的提交，右键选择Compare with Previous - 重点观察：他删掉了什么？注释掉的旧校验是否仍保留在 git history 中？
git log -S "verifyPayment"可能比单行 blame 更早暴露问题源头 - 对关键函数，用
GitLens: Show Commit Graph查看其所在文件的完整变更脉络，尤其注意那些带refactor、cleanup标签却修改了核心判断路径的提交
真正的审计难点不在“怎么查”，而在“查哪一层”。GitLens 提供的是时空坐标，但决定往哪个坐标钻、钻多深，得靠你对业务风险的理解——比如时区处理、金额计算、权限校验这类逻辑，永远要往前翻至少 3 个相关 commit，而不是只信最后一笔。
