lint-staged 从入门到实战：基于 Git 暂存区的增量代码检查方案

lint-staged 这个工具，几乎所有做前端工程化的人迟早都会碰到。但它到底解决了什么问题、为什么能解决、什么时候其实没必要上它，很多人只是照着文档配了一遍就没再深究。我在几个项目里把它从零到一落地过，也踩过不少配置之外、文档里不会写的坑，这篇文章就把我实际使用中的理解和经验一次性说清楚。

1. 为什么需要 lint-staged：全量 lint 的卡顿困境

先说一个最常见也最容易被忽略的痛点：当项目运行 eslint . 或者 eslint src 的时候，表面上看是“检查整个项目的代码质量”，实际在稍微大一点的项目里，这个命令跑一次可能要十几秒甚至几十秒。如果还挂了 stylelint、prettier --check、类型检查之类，一套组合拳下来，每次提交代码前光等校验就够喝一壶的。

这个问题的根源在于，很多 lint 工具没有做增量缓存机制，每次执行都会重新解析所有文件。哪怕你只改了一个文件里的一个变量名，eslint . 依然会把整个 node_modules 之外的全部源码翻一遍。在项目几百个文件起步、引入了 TypeScript 和一堆复杂规则之后，这个成本会指数级上升。而 lint-staged 的核心设计思路就是：不要检查全部文件，只检查 Git 暂存区里那些即将被提交的文件。

也就是说，它的名字其实已经解释了它的一切行为——staged 在 Git 语境里是“已暂存”的意思，lint-staged 就是“对已暂存的文件执行 lint 检查”。它通过 git diff --name-only --cached 之类的底层命令，找到当前暂存区里的文件列表，然后只把这些文件交给 eslint、prettier、stylelint 去处理。

这种思路带来的体验提升是立竿见影的。假设项目一共 800 个文件，你这次提交只改了 3 个文件，lint-staged 只会 lint 这 3 个，耗时从十几秒直接降到一两秒甚至几百毫秒。而且因为每次只处理少量文件，即使某个文件出了问题，报错信息也聚焦得多，修复起来更快。可以说，lint-staged 是 Git hooks 时代让“提交前自动校验”变得真正可用的关键一环。

有人可能会问：那我不在提交时跑，靠编辑器里的 ESLint 插件实时报错不行吗？当然可以，编辑器插件是开发期的第一道防线，但它的覆盖面取决于编辑器是否加载了正确的配置、是否覆盖了所有文件类型、以及开发者有没有打开对应文件。lint-staged 的价值在于它作为提交前最后一道强制关卡，不受编辑器状态影响，只要代码进入暂存区，就必然走一次校验，跑不掉的。这一道关卡，配合 Husky 之类的 Git hooks 管理工具，才能真正做到“不合格的代码进不了提交历史”。

2. 从依赖到流水线：lint-staged 的底层工作流程拆解

lint-staged 的工作流程，如果拆开来看，其实就是一个非常清晰的管道（pipeline）。它做的事情不一定复杂，但顺序和细节直接影响最终的可靠性。理解了这个流程，后面配置里很多“奇怪”的现象就都能解释通了。

2.1 它如何知道要检查哪些文件

这是整个工具最关键的一步。lint-staged 底层会调用 Git 命令，默认逻辑大致是：通过 git diff --name-only --cached --diff-filter=ACMR 获取当前暂存区中已添加、已复制、已修改、已重命名的文件列表。注意它默认排除了删除（D）的文件，因为文件都删了，lint 它没有意义；同时它也只会拿到“相对仓库根目录的路径”，而不是绝对路径。

这里面有一个很容易被忽略的能力：lint-staged 支持配置 --diff 参数，你可以让它基于任意两次提交之间的差异来生成文件列表，而不局限于“当前暂存区”。这在某些 CI 场景下非常有用，比如你只想检查某个 MR 里与上一个版本相比改动的文件。不过日常本地提交，绝大多数场景用的都是默认的暂存区模式。

2.2 匹配规则是怎么过滤文件的

拿到文件列表之后，lint-staged 会拿着这个列表去和你配置里的 glob pattern（也就是 *.js、*.ts、*.{js,vue} 之类的匹配模式）做匹配。只有同时满足下面两个条件的文件才会交给对应的 lint 命令：

• 该文件确实在 Git 的暂存区里（或在你通过 --diff 指定的变更集里）。
• 该文件的路径能匹配上配置中的某个 glob 模式。

举个例子，如果你配置的是 "*.js": "eslint --fix"，那么暂存区里即便有 foo.ts 和 bar.js，也只有 bar.js 会被送去 lint。这也意味着，如果某个文件类型你忘了写对应的匹配规则，它就会像空气一样直接放行，不会报错——这是配置里最隐蔽的“静默失效”方式之一，后面我会专门讲。

2.3 任务执行顺序和文件暂存回写

文件匹配完成之后，lint-staged 会把每个匹配模式对应的命令并发地跑起来。默认情况下，多个任务之间是并行的，这也是它能保持高速的原因之一。但这里有一个非常经典的坑：如果两个任务处理的是同一批文件的同一区域，比如 eslint --fix 和 prettier --write 同时跑，最终结果就可能会互相覆盖，导致文件被改了一半、格式化了一半，甚至产生语法错误。

文档里其实早就给出了建议，那就是使用 && 把多条命令串联起来，让它们按顺序执行：

json复制{
  "lint-staged": {
    "*.{js,jsx,ts,tsx}": "eslint --fix && prettier --write"
  }
}

这里 eslint --fix 先把可自动修复的代码风格问题修掉，再交给 prettier --write 做最后的格式化。顺序上尽量把 ESLint 放在 Prettier 前面。因为 Prettier 的格式化会重排代码结构，你在 ESLint 里设定的某些规则（比如 indent、max-len）可能依赖原始行结构，先 Prettier 再 ESLint 有可能导致 ESLint 再次改动 Prettier 刚格式化好的代码，造成“格式化结果不稳定”的循环。先 ESLint 再 Prettier，让 Prettier 做最终输出，是更稳定的顺序。

另一个隐蔽的点是：lint-staged 在执行完任务之后，如果你用的命令带 --fix 或 --write 这类会修改文件的参数，它会把修改后的内容重新 add 回暂存区。这是它默认行为的一部分，目的就是保证你提交进去的代码是修复过后的版本，而不是修复前的旧版本。理解这一点很重要，因为如果某个命令执行失败，lint-staged 会中止后续操作并打印“Some of your tasks use git add command”之类的警告，提醒你任务可能没有正确回写暂存区。

提示：lint-staged 之所以在较新版本里不再推荐在命令里手动加 git add，就是因为自动回写暂存区已经内置了。如果你在命令末尾手动写 && git add，反而可能造成重复添加或掩盖某些错误。

2.4 失败时的行为

如果某个文件 lint 之后发现问题且命令以非零状态码退出，lint-staged 会立即中断整个流程，把错误信息打印到终端，并且不会提交。这正是它在 Git hooks 里的价值所在：一个失败的命令能让整个提交流程夭折。

这里有个小细节：lint-staged 默认在执行任务前，会先把当前暂存区里的文件内容保存成 patch，任务失败后会尝试把暂存区恢复到执行前的状态。这个设计的目的是防止某些任务因为并发或其他原因把文件改到一半，导致你的工作区处于一个“改了但没完全改”的混乱状态。但它并不是绝对可靠的，所以自己还是要小心：如果 lint-staged 执行途中被强杀（比如你按了 Ctrl+C），有可能留下一个不完整的 patch 文件或脏工作区，这时用 git stash list 和 git status 检查一下比较稳妥。

3. 配置 lint-staged：从 package.json 到独立配置文件的完整落地

lint-staged 的配置方式非常灵活，可以在 package.json 里加 lint-staged 字段，也可以用独立的配置文件（.lintstagedrc、.lintstagedrc.json、.lintstagedrc.yaml 或 lint-staged.config.js）。个人建议：如果项目里已经有 package.json 且配置项不多，直接写在 package.json 里最省事；如果规则多、模式复杂，拆到独立配置文件里会更清晰，也方便单独维护。

3.1 最基础的一份配置长什么样

先给一份我在中型 Vue 3 + TypeScript 项目里实际用过的配置，你可以直接抄：

json复制{
  "lint-staged": {
    "*.{js,jsx,ts,tsx,vue}": [
      "prettier --write",
      "eslint --fix"
    ],
    "*.{css,scss,less}": [
      "prettier --write",
      "stylelint --fix"
    ],
    "*.{json,md,yml,yaml}": "prettier --write"
  }
}

把 prettier --write 放在数组第一位，是让它先把格式修一遍，然后 eslint/stylelint 再按照规则检查并修复。注意如果你用了数组形式，lint-staged 会串行执行数组里的每一项，所以不需要手动加 &&。但如果你把命令写成字符串，比如 "*.{js,vue}": "prettier --write && eslint --fix"，那就得自己加 && 了。这两者在行为上基本等价，但数组形式在视觉上更清晰，也更容易追加命令。

这里有一个容易踩的坑：如果你用 eslint --fix 修复之后，ESLint 又修改了文件内容，lint-staged 会自动把修改后的文件重新 add 到暂存区。但是如果 eslint --fix 执行成功但没有修改文件，它仍然会正常通过。如果你的 ESLint 版本很老，或配置里某些规则无法自动修复，提交时就会看到报错，告诉你哪些文件的哪些 rule 有问题。这是预期行为，不是 lint-staged 的 bug。

3.2 独立配置文件写法

如果你更喜欢把配置独立出来，创建一个 lint-staged.config.js：

javascript复制module.exports = {
  '*.{js,jsx,ts,tsx,vue}': ['prettier --write', 'eslint --fix'],
  '*.{css,scss,less}': ['prettier --write', 'stylelint --fix'],
  '*.{json,md,yml,yaml}': 'prettier --write'
}

也可以写成 .lintstagedrc.json：

json复制{
  "*.{js,jsx,ts,tsx,vue}": ["prettier --write", "eslint --fix"]
}

需要注意一点：当项目里同时存在多种配置文件时，lint-staged 只会按优先级读取其中一个，优先级顺序大致是 package.json 的 lint-staged 字段、.lintstagedrc、lint-staged.config.js 等。如果你从 package.json 迁移到独立文件，记得把原来的字段删掉，否则很可能出现“你改了配置文件但不生效”的诡异情况。

3.3 关键配置项：任务并发、忽略文件、shell 解析

除了核心的匹配规则，lint-staged 还有几个配置项值得单独说一下：

json复制{
  "concurrent": false,
  "ignore": ["dist/**", "node_modules/**"],
  "shell": false,
  "verbose": true
}

• concurrent: 默认是 true，所有任务并发执行。如果任务之间有依赖关系，或者你想让日志更清晰地按顺序输出，可以显式设为 false。不过并发通常更快，非必要不建议关。
• ignore: 在匹配结果基础上追加忽略列表。比如你暂存了 dist/output.js，即使它的路径匹配了 *.js，也会因为 ignore 里的 dist/** 被跳过。注意，如果你在命令行用 --ignore 传参，和配置文件里的 ignore 是追加关系还是覆盖关系，不同版本行为不完全一样，升级版本后最好再跑一次看看。
• shell: 默认 false，表示 lint-staged 会直接用 Node.js 的 spawn 执行命令，不经过 shell 解析。这带来一个行为差异：如果你命令里用了 &&、|、> 这类 shell 操作符，在 shell: false 时会被当成普通参数传给命令，而不是被 shell 解析。这也是为什么很多人会发现 "*.js": "eslint --fix && prettier --write" 在某些环境下不生效——因为中间那个 && 没被解析。解决办法就是要么使用数组形式让 lint-staged 串联，要么把 shell 设为 true。但从安全性和跨平台角度，我更推荐数组形式。

verbose 项可以在命令执行时打印更详细的过程信息，排查问题时很有用。日常不需要开，但如果你遇到“提交时明明配置了规则却好像没跑”的疑问，把 verbose: true 开起来看输出，问题会暴露得很快。

3.4 配合 Husky 的完整接入

lint-staged 本身不会自动在 Git 提交时触发，它需要挂在 Git 钩子上。社区最常用的搭配是 Husky。Husky 的接入方式不同版本差异很大，这里以目前主流的 Husky 9 为例：

bash复制npx husky init

这会在项目里生成 .husky/pre-commit 文件，然后你把它改成：

bash复制npx lint-staged

就完成了。后续每次 git commit 时，npx lint-staged 会被自动执行。

如果你用的是 Husky 4 或更早版本，则通常是在 package.json 里配置：

json复制{
  "husky": {
    "hooks": {
      "pre-commit": "lint-staged"
    }
  }
}

这里有一个很现实的问题：npx lint-staged 每次执行都会先检查本地是否安装了 lint-staged，如果项目里没有安装它会尝试从 npm 下载，这在离线或内网环境会很蛋疼。更稳妥的做法是在项目 devDependencies 里显式安装 lint-staged，并在 husky 钩子里直接写 lint-staged（前提是 npm scripts 能解析到本地 node_modules/.bin）。如果你用的是 pnpm，需要注意 pnpm 的 node_modules/.bin 符号链接行为略有差异，但通常也能正常解析。实在不行，可以在项目 package.json 的 scripts 里加一条 "lint:staged": "lint-staged"，然后在 husky 钩子里写 npm run lint:staged，这样最保险。

4. 真实项目中的踩坑记录：那些文档没写清但一定会遇到的事

配置本身不难，难的是配置完之后“为什么没生效”或者“为什么报错”的排查过程。我把过去实际踩过、也在同事项目里帮忙排查解决的几个高频问题列在这里，每个都附带根因和解决方案。

4.1 问题一：为什么我明明改了文件，lint-staged 却不检查它

这是最常见的困惑。排查链路如下：

1. 先确认文件是否真的被 git add 了。lint-staged 只看暂存区，git add 之前它完全无感知。
2. 再确认暂存区里有没有这个文件：git status --short 看看文件状态是否以 A 或 M 开头。
3. 然后确认匹配规则有没有覆盖到这个文件后缀。比如你只配了 *.js，暂存了一个 .jsx 文件，它就不会被检查。
4. 最后检查 ignore 配置有没有把它排除。

曾经有同事把 .vue 文件配置写成了 *.{vue} 这种看起来没问题的写法，但实际因为 glob 版本或配置解析的细微差异，某些环境下匹配不上。虽然 {} 写法在多数字符串里是合法的，但建议写成 *.vue 或 *.{js,ts,vue} 这样明确的模式，不要写多余的嵌套括号。

4.2 问题二：Windows 环境下 lint-staged 命令执行失败

在 Windows 上使用 lint-staged，最常见的报错是命令找不到，或者在 prettier --write 和 eslint --fix 的顺序执行时出现奇怪的问题。根因通常是 shell 解析差异。Windows 的默认 shell 是 cmd.exe，和 Linux 下的 bash 完全不同。如果你在配置里写了 prettier --write && eslint --fix，在 Linux/macOS 上没问题，但在 Windows 的 cmd 里 && 其实也能解析，只是某些引号或路径带空格的场景会导致解析错乱。

更稳妥的方案是统一使用数组形式，并且避免在命令里直接引用带空格的文件路径。如果你遇到了路径空格问题，可以试试在命令前加上 cross-env shell，或者直接改用 npx lint-staged 并通过 .husky/pre-commit 里的调用方式规避。团队里有人用 Windows 有人用 macOS 时，推荐在 package.json 里增加 cross-env 并统一 scripts 写法，能在很大程度上减少环境差异带来的坑。

4.3 问题三：prettier --write 和 eslint --fix 互相覆盖怎么办

上面说过了，把这两个命令写进同一个数组顺序执行，是合理的。但如果它们不在同一个数组里，而是配成了两个独立的 key：

json复制{
  "*.{js,jsx,ts,tsx,vue}": ["prettier --write"],
  "*.{js,jsx,ts,tsx,vue}": ["eslint --fix"]
}

这样写会导致两个完全相同的 key，ESLint 修复后的文件可能又被 Prettier 重置格式，或者反过来。正确做法是合并到一个 key 下，排序为 prettier --write 在前，eslint --fix 在后。如果你希望 ESLint 先检查并修复，再交给 Prettier 兜底，那就反着排。但记住要保持它们在一个 key 下按顺序执行，不要拆到两个 key 里。

4.4 问题四：lint-staged 执行成功，但提交的内容是修改前的版本

这个问题比较隐蔽。原因在于：lint-staged 会把修复后的文件重新 add 回暂存区，前提是它知道文件变了。但如果你的命令是通过 shell: true 方式跑的，并且命令里自己加了 git add，而 lint-staged 同时又在后面做了一次 add，理论上没问题；但如果你用了某些自定义脚本，脚本内部执行了 git checkout 或 git stash，就可能导致暂存区内容被回滚。另外，如果你的 lint 命令只做了检查（比如 eslint 不带 --fix），文件内容没变，那么暂存区保持原样，提交进去自然也是原样。所以遇到“提交的代码没被格式化”的问题，先确认自己是否用了带 --fix/--write 的修复命令。

4.5 问题五：lint-staged 报错说 “✖ Some of your tasks use git add”

我刚开始用 lint-staged 时也见过这个提示。它通常出现在某些历史版本的项目中，因为老版本的 lint-staged 文档里推荐在命令末尾加 git add 来把修改后的文件重新暂存；而新版本已经内置了这个行为，你再手动添加就会触发警告。

遇到这个警告，正确做法是把命令里手动加的 git add 删掉。例如：

json复制{
  "*.{js,ts}": "prettier --write && eslint --fix && git add"
}

改成：

json复制{
  "*.{js,ts}": ["prettier --write", "eslint --fix"]
}

就能消除警告，而且行为完全正常。这个提示本身不是硬错误，但最好清理掉，因为它会影响日志的清晰度，也可能掩盖真正的路径或权限问题。

5. 进阶玩法：类型检查、自定义脚本、文件扩展名细节

lint-staged 不仅能跑 eslint/prettier，它本质上是一个“对指定文件集执行任意命令”的通用工具。所以很多团队会把它扩展成各种提交前检查的入口。

5.1 在 lint-staged 里跑 TypeScript 类型检查

最常见的进阶需求是在提交前做 TypeScript 类型检查。但是这里要特别注意：tsc --noEmit 是全局项目级命令，不是文件级命令，你把 "*.ts": "tsc --noEmit" 写进 lint-staged，它会收到 lint-staged 传过来的文件列表参数，但 tsc 并不认“单个文件”这种用法。如果你真这样配置，很大概率会直接报错，或者检查范围完全超出预期。

业界常见的做法是，让 lint-staged 只负责对文件做快检查（比如 eslint、prettier），而类型检查这类全局任务，要么在 pre-commit 钩子里单独执行，要么在 CI 里执行。如果你想放在同一条钩子里，可以这样写：

bash复制npx lint-staged && npm run type-check

这样 lint-staged 只处理文件级检查，type-check 再对整个项目做一次完整类型检查。虽然类型检查耗时没有完全优化掉，但至少你的 lint 部分享受到了增量加速。

如果你真的想在 lint-staged 里用 tsc，也可以自己写一个小脚本，接收 lint-staged 传入的文件列表，然后用 TypeScript 的 API 动态更新 tsconfig 里的 include，按单个文件或少量文件做类型检查。这在超大项目里能显著提升提交时的类型校验速度，但实现成本不低，一般中小型项目没必要上。

5.2 lint-staged 配合自定义脚本

因为 lint-staged 的规则值本质上就是 shell 命令模板，加上 {stagedFiles} 占位符可以显式引用文件列表。比如自定义一个脚本，只校验某些文件的命名规范：

json复制{
  "*.{js,ts}": ["eslint --fix", "node scripts/check-filename.js {stagedFiles}"]
}

其中 {stagedFiles} 会被 lint-staged 解析成匹配上的文件列表字符串，多个文件用空格分隔。不过要注意，如果文件路径里有空格，这个占位符展开后可能导致命令解析出错。在团队协作项目里，最好保证文件路径不包含空格，否则需要自己在脚本里处理路径。

5.3 文件扩展名细节：大小写、点号和 glob 匹配

lint-staged 的匹配规则用的是 micromatch（或类似 glob 实现），它对点文件的匹配有一些特殊规则。比如 .eslintrc.js 这种文件，默认情况下通配符 * 可能不会匹配以点开头的文件。如果你希望 lint-staged 能处理类似 .prettierrc、.stylelintrc 这些文件，需要显式在 glob 里写 .*.js 或 **/.* 之类。

还有一点：glob 匹配是区分大小写的，*.JS 不会匹配 foo.js。在 Windows 和 macOS 这种文件系统大小写不敏感的环境下，开发时可能没发现问题，但 CI（通常是 Linux）上就可能出现“本地能跑、CI 不跑”的诡异差异。所以尽量把可能出现的后缀都显式列全，比如 *.{js,jsx,ts,tsx,mjs,cjs}。

5.4 只让 lint-staged 处理文档和资源文件

有团队会把 lint-staged 扩展成只对 Markdown 做 spellcheck、对图片做压缩。这本质上是同一个机制，只要命令能接收文件路径作为参数就可以。例如：

json复制{
  "*.md": ["prettier --write", "markdownlint --fix"],
  "*.{png,jpg,jpeg,webp}": ["imagemin-lint-staged"]
}

这种用法在文档型项目或静态站点项目里很实用。不过也别把所有工具都塞进 pre-commit，提交钩子太重的话反而会拖慢开发节奏。逻辑上只放那些“文件级、快速、可自动修复”的检查就够了。

6. 性能、CI 与 monorepo：lint-staged 在更大场景下的表现

前面讲的大多是单仓库下最简单的使用方式，但 lint-staged 在 monorepo、CI 流水线等场景下同样很常用，只是需要多一些配置技巧。

6.1 monorepo 下的配置策略

在 pnpm workspace 或 npm workspace 构成的 monorepo 里，每个子包可能有自己的 ESLint/Prettier 配置。lint-staged 如果只在根目录配一份，无法覆盖每个子包的特殊配置。最合理的做法是把 lint-staged 配置放到各个子包里，然后通过 lint-staged 的 --cwd 参数或在 husky 钩子里进入子包目录执行。

但这样又会带来一个问题：根目录的 pre-commit 钩子里执行一次 lint-staged，可能只会处理 cwd 下的暂存文件，而不是整个仓库的暂存文件。社区里的常见方案是使用 lint-staged --diff 或配合 git diff --name-only --cwd 之类的逻辑，在钩子脚本里对每个子包分别执行。

不过说实话，中小型 monorepo 如果每个子包的 lint 规则相差不大，直接在根目录配置一份，然后用 eslint --fix 配合 .eslintrc 里的 overrides 按目录区分规则，反而更简单。monorepo 的 lint-staged 完整方案值得单独写一篇文章，这里不展开，但你只要知道：它的瓶颈不在运行速度，而在于配置怎么跟工作区结构匹配。

6.2 在 CI 里用 lint-staged 审核 MR 改动

CI 里使用 lint-staged 的场景通常是：不想对整个项目跑全量 lint，只想快速检查 MR 中变更过的文件。此时可以在 CI 命令里用：

bash复制npx lint-staged --diff="origin/main...HEAD"

这样 lint-staged 会比较 origin/main 和当前 HEAD 的差异，提取变更文件列表，然后只对它们执行 lint。这在 MR 很多、又想快速反馈的团队里非常实用。需要注意 --diff 与默认的暂存区模式互斥，CI 环境下没有 git add 概念，所以必须显式传 --diff 或者用 git diff --name-only HEAD~1 HEAD 这类命令自己生成文件列表再传给 lint-staged 的 --diff-from、--diff-to 参数。

6.3 性能对比：全量 lint vs lint-staged

我用一个约 1200 个 TypeScript 文件的中型前端项目做过一次粗测，统一用 time 记录：

当然，这个数字跟机器性能、ESLint 规则复杂度、文件大小都有关，但结论是确定的：改动文件数量少的时候，lint-staged 的耗时几乎是“感知不到”的。这也是为什么它能成为本地提交钩子的首选方案。

6.4 版本升级可能带来的行为变化

lint-staged 从 v10 到 v15，行为细节一直在变。比较大的变化包括：v10 开始默认恢复暂存区，v12 开始增强了对 --diff 的支持，v14 把 Node 版本要求提高，v15 对配置文件解析、shell 行为、任务执行顺序都有调整。如果你是从老版本直接升上来，一定要跑一遍完整的 git commit 流程验证，不要只跑 lint-staged --version 看一眼就以为没事。

我遇到过最典型的情况是：项目原本锁在 lint-staged@10，某天同事升级到 lint-staged@15，结果所有任务突然都变成“不生效”了。排查发现是 v15 不再默认把 shell 设为 true，导致原来字符串里的 && 全部失效。如果你也遇到类似问题，先检查 shell 配置和命令的组成形式，八成能解决。

7. 常见问题自查表

日常被问到最多的几个问题，我整理成一张自查表，方便你遇到的时候快速定位：

8. 我最后想说的话

lint-staged 本身是一个极简工具，但它的价值并不在于“跑得快”这一件事，而在于它改变了团队代码提交前的工作流：把全量检查变成了增量检查，把“提交前要手动跑一堆命令”变成了“一条钩子自动搞定”。它让我意识到，工程化改造的很多收益，并不来自引入复杂系统，而来自像这样把一个环节从“全量”精确到“最小必要集合”的优化。如果你还没在自己的项目里接入 lint-staged，从一份最小配置开始，配合 Husky 跑一星期，你会慢慢感受到 Git 提交质量提升带来的安心感。