GitLens 行内 blame 需手动启用 gitlens.blame.lineEnabled 并正确配置 ignoredScopes、Git 路径及缓存刷新；行历史可追溯完整演化路径，支持对比多版本与函数级差异，但依赖 Git 命令输出，异常配置需终端验证。
GitLens 能直接在编辑器里看到每行代码是谁写的、什么时候改的、为什么改——但前提是配置对了，否则只会显示“No history available”。
启用 GitLens 的行内 blame 视图
默认安装后 GitLens 不会自动显示行级作者信息，必须手动开启。打开 VSCode 设置（Ctrl+,），搜索 gitlens.blame.lineEnabled，勾选它；再确认 gitlens.blame.ignoredScopes 没误删 source 或 comment——否则注释和字符串里的行会不显示 blame。
- 如果文件是未跟踪的新建文件，blame 为空是正常的，不是插件问题
- 使用 WSL 或远程开发时，确保 Git 可执行路径在
git.path设置中指向正确位置（比如/usr/bin/git） - blame 信息缓存默认 5 分钟，改完 commit 立即想看到更新？按
Ctrl+Shift+P→ 输入GitLens: Refresh File Blame Annotations
用 GitLens 查看某行的历史变更链
把光标停在某一行，右键选择 GitLens: Show Line History，或快捷键 Alt+H L（Windows/Linux）/Option+H L（macOS）。这不是简单列出 commit，而是构建出该行从首次出现到现在的完整演化路径。
- 历史面板里点某个 commit，右侧会高亮显示本次修改影响的行范围（add/remove/modify）
- 如果某次提交只改了空格或换行，GitLens 默认折叠这类“无关变更”，可在设置中关闭
gitlens.history.excludeTrivialCommits - 遇到 merge commit 卡住？检查是否启用了
gitlens.advanced.git?.enableCommitSigning，签名验证失败会导致历史加载中断
对比两个版本间某函数的完整改动
右键函数名 → GitLens: Compare With Previous Revision 是常见操作，但容易漏掉跨文件重构。更稳的方式是：先用 GitLens: Open File Timeline 打开当前文件所有 commit 记录，然后按住 Ctrl（或 Cmd）多选两个关键版本，再右键 → Compare Selected Revisions。
- 对比结果里，函数签名变化会被识别为“重命名”，但 GitLens 不会自动追踪 rename，需手动确认
git config diff.renameLimit是否足够大（建议设为999999） - 如果对比窗口里看不到函数体差异，检查是否开启了
gitlens.diff.codeLens.enabled，这个开关控制函数级差异的 inline 显示 - 大型仓库中，频繁触发全量 diff 可能卡顿，可临时禁用
gitlens.codeLens.enabled减少干扰
GitLens 的深度依赖 Git 命令的真实输出，而不是自己解析 .git 目录。这意味着它很准，但也意味着任何本地 Git 配置异常（比如自定义 core.pager、diff.algorithm）都可能让某些视图空白或报错——遇到诡异情况，先在终端跑一遍等效的 git log -L 或 git blame 命令，比对着看输出差异最有效。
