GitLens 本身不记录版本，仅可视化 Git 提交历史，需先初始化仓库并完成 git add/commit；右键选“Show Line History”可追溯某行完整修改链，状态栏无分支名则功能失效。
VSCode 插件本身不管理 JavaScript 代码版本，真正起作用的是 Git + 插件增强组合。GitLens、ESLint、Prettier 这三类插件各自承担不同角色，配合得当才能让版本变更可追溯、代码质量不退化、格式不打架。
GitLens 怎么看 JS 文件的历史变更
GitLens 不是“自动记录版本”，它只是把 Git 已有的提交历史、分支差异、作者信息可视化地叠加在编辑器里。关键点在于：你必须已用 git init 初始化仓库，且每次修改后执行过 git add 和 git commit，GitLens 才有数据可展示。
- 右键某行 → “GitLens: Show Line History” 能看到这行代码最早在哪次提交中出现、谁写的、后续被谁改过
- 按
Ctrl+Shift+P输入GitLens: Compare With Previous Revision可快速对比当前文件与上一个 commit 的差异 - 如果状态栏没显示分支名或提交哈希，说明当前文件不在 Git 仓库下，GitLens 功能全部灰掉
ESLint 和 Prettier 在 commit 前怎么协同工作
ESLint 负责语义层修复（比如 var → const、== → ===），Prettier 负责纯样式重排（缩进、括号换行、引号类型）。两者直接共用 editor.formatOnSave 就会互相覆盖，导致部分规则失效。
- 关闭
"editor.formatOnSave": true（尤其在[javascript]块里） - 启用
"editor.codeActionsOnSave": {"source.fixAll.eslint": true}，让 ESLint 在保存时接管所有可修复项 - 确保
.eslintrc.cjs中extends包含"plugin:prettier/recommended"，且已安装eslint-plugin-prettier和eslint-config-prettier - 提交前手动运行
npx eslint --fix .是兜底手段，但不应依赖——配置对了，保存即修复
为什么 pre-commit hook 里跑 ESLint/Prettier 比插件更可靠
插件只在你本地 VSCode 里生效；别人用 WebStorm 或命令行 git commit 时，插件完全不起作用。靠 husky + lint-staged 在 commit 触发前强制校验，才是团队统一底线。
- 运行
npx husky install后，再npx husky add .husky/pre-commit "npx lint-staged" -
lint-staged配置里必须明确指定**/*.js文件走eslint --fix，**/*.{js,jsx,ts,tsx}走prettier --write - 如果
package.json里engines.node设为>=18.0.0，但 CI 环境用的是 Node 16，hook 会直接失败——版本约束要和实际环境对齐
最容易被忽略的点是：GitLens 显示的“上次修改人”可能不是真正逻辑改动者，而是合并冲突时执行 git merge 的人；ESLint 的 fix 会改写代码 AST，但不会更新 Git 的 staging 状态——commit 前务必确认 git status 显示的变更确实是你要提交的内容。
