GitLens安装需VSCode 1.70+，国内用户应检查代理或切换市场源；行内blame仅对已暂存文件生效；关闭autoShow可缓解卡顿；查行历史应优先用文件历史视图而非blame。
GitLens 插件装不上？检查 VSCode 版本和市场连接
GitLens 要求 VSCode 1.70+，旧版本会直接显示“不兼容”或安装后禁用。打开 Help → About 确认版本号；如果低于 1.70，先升级 VSCode 再操作。
国内用户常见问题是插件市场加载失败或搜索无结果——这不是 GitLens 的问题，而是 VSCode 默认市场服务器访问不稳定。解决方法：
• 打开 Settings → Application → Proxy，确认代理配置没误启（尤其开了全局代理但未配置 VSCode 代理）
• 或临时切换市场源：在设置中搜索 extensions.gallery，把 serviceUrl 和 cacheUrl 改为 https://marketplace.visualstudio.com/_apis/public/gallery（注意末尾无 /）
安装路径是：左侧活动栏点扩展图标 → 搜索框输 GitLens → 找到作者 GitKraken 的官方插件 → 点安装 → 重启 VSCode（部分功能需重启才生效）
启用行内提交信息前，先确认当前文件已纳入 Git 仓库
GitLens 的「行内 blame」（每行右侧显示提交人、时间、commit ID）只对 git add 过的文件生效。新创建未暂存的文件、.gitignore 排除的文件、或工作区根本没初始化 git init，都会显示灰色虚线或“Not in repository”提示。
快速验证：
• 终端执行 git status，确保文件在 “Changes to be committed” 或 “Modified” 列表里
• 在 VSCode 底部状态栏看是否有分支名（如 main），没有说明没进 Git 上下文
• 右键编辑器空白处，菜单里若无 GitLens: Toggle Blame Annotations，大概率是仓库未识别
别急着调设置——先 git add . + git commit -m "init"，再刷新编辑器，行内信息通常立刻出现。
blame 显示太乱？关掉自动更新和高频刷新
默认开启的 gitlens.blame.autoShow 会在每次光标移动时重算 blame，大文件（>500 行）或慢磁盘（如网络盘、老旧机械硬盘）会卡顿，甚至导致 VSCode 响应延迟。
建议调整：
• 关闭自动触发：设置中搜 gitlens.blame.autoShow，设为 false
• 改用手动唤出：右键代码行 → GitLens: Show Line Blame，或快捷键 ctrl+alt+h（Windows/Linux）/cmd+alt+h（macOS）
• 如仍需常驻，把刷新间隔拉长：搜 gitlens.blame.refreshInterval，从默认 5000（毫秒）改为 30000
注意：gitlens.advanced.blame.ignoreWhitespace 默认为 true，这意味着换行/缩进修改不会触发 blame 更新——如果你正调试格式改动引发的问题，记得临时关掉它。
想查某行的历史变更？别只盯着 blame，用“历史”视图定位更准
blame 只显示“最后一笔改这行的人”，但你真正需要的可能是“这行最早哪次提交引入的？”或者“中间被谁删过又加回来？”——这时 GitLens: Open File History（右键文件标签或编辑器 → 选择该命令）更可靠。
关键操作：
• 文件历史视图里，点击某次 commit 左侧的 ⋯ → Compare with Previous，能看清这行是新增、删除还是修改
• 想追溯单个函数的演化：选中函数名 → 右键 → GitLens: Compare Against Previous Commit，跳转对比视图
• 如果某次 commit 后这行消失了，但在后续 commit 又出现，说明被 revert 或重写过——此时 blame 会跳过中间空档，直接连到最近一次“存在”的提交
一个容易忽略的细节：git blame -w（忽略空格）在 GitLens 里由 gitlens.blame.ignoreWhitespace 控制，但它的效果仅作用于 blame 显示，不影响文件历史视图里的 diff 计算逻辑。
