lint-staged 本身不监听 git 操作，仅是执行器，必须由 husky 在 pre-commit 钩子中调用才能生效；若未运行 npx husky install 或 .husky/pre-commit 中未正确配置 npx lint-staged，则提交时无任何反应。
为什么 lint-staged 要配合 Husky 才能生效
因为 lint-staged 本身不监听 Git 操作，它只是个“执行器”：只对暂存区（git add 后的文件）跑命令，不会自动触发。没 Husky，它就永远等不到被调用的时机。
常见错误现象是：配好了 lint-staged，也写了 prettier --write，但 git commit 时完全没反应——大概率是 Husky 的 pre-commit 钩子没装好或没启用。
- 运行
npx husky-init或npx husky install是必须步骤，否则.husky/目录不会生成 -
.husky/pre-commit文件里必须包含可执行命令，比如npx lint-staged（注意不是npm run lint-staged） - Windows 用户若用 Git Bash 提交，需确认钩子文件有执行权限；PowerShell 下可能需额外设置
Set-ExecutionPolicy RemoteSigned -Scope CurrentUser
lint-staged 配置中通配符和命令顺序很关键
lint-staged 不是全局扫文件，它严格按你写的 glob 模式匹配暂存文件，且命令数组是**顺序执行**的——前一个命令改了文件，后一个命令才能看到新内容。
典型陷阱：把 "prettier --write" 和 "git add" 写反了，或者漏掉 git add，会导致格式化后的变更没进暂存区，commit 仍提交旧代码。
- 推荐写法：
"*.{js,ts,jsx,tsx}": ["prettier --write", "git add"] - 如果同时用 ESLint 修复，顺序应为
["eslint --fix", "prettier --write", "git add"]，避免 Prettier 格式化后 ESLint 又报风格警告 - 不要写
"**/*.{js,ts}"——lint-staged默认只查暂存文件，**/多余且可能匹配失败；直接用*.{js,ts}更稳
VSCode 保存格式化和 lint-staged 的分工要分清
VSCode 的 editor.formatOnSave 是本地开发体验优化，而 lint-staged 是团队准入卡点。两者共存时，容易因配置冲突导致重复格式化、光标跳动或保存变慢。
最常被忽略的一点：VSCode 保存时若已用 Prettier 格式化过，lint-staged 再跑一次其实是冗余的——除非你允许开发者跳过保存直接 commit。
- 建议 VSCode 配置中明确限定语言范围，比如：
"[javascript]": { "editor.formatOnSave": true }，避免对 JSON、CSS 等非逻辑文件误触发 - 禁用
editor.formatOnSave全局开关，改用语言专属配置，能减少与lint-staged的行为重叠 - 如果项目强制要求提交即规范，可考虑关掉 VSCode 保存格式化，只依赖
lint-staged—— 这样所有格式化行为都集中、可审计、不因人而异
prettier --write 在 lint-staged 中的实际执行路径
lint-staged 调用 prettier --write 时，不会读取 VSCode 插件里的设置，而是**只认项目根目录下的 .prettierrc、prettier.config.js 或 package.json 中的 prettier 字段**。
很多人配了 VSCode 的 settings.json 以为就够了，结果 commit 时格式还是不对——因为 lint-staged 根本不看那个文件。
- 务必在项目根目录放一份
.prettierrc，内容如：{"semi": true, "singleQuote": true, "trailingComma": "es5"} - 如果用
prettier.config.js，注意导出必须是module.exports = {...}，ESM 语法（export default）在 Node.js - CI 环境中若没装 Prettier 依赖，
lint-staged会直接失败，所以prettier必须是devDependencies
