如何用lint-staged提升代码质量并避免团队协作中的常见问题

谁更省事？三种lint-staged的实现方式对比

最近在几个项目里都用到了 lint-staged，踩了不少坑也积累了一些经验。说起来，这个工具虽然小，但选型的时候还挺纠结的。今天就来聊聊我常用的三种方案：纯 lint-staged、结合 husky 的方案，以及自定义脚本的方式。

先说结论：我更喜欢用 lint-staged + husky 的组合。这个搭配不是最灵活的，也不是性能最好的，但它足够简单好用，而且社区支持很强，踩坑成本低。下面我会详细讲讲为什么。

方案一：纯 lint-staged

最简单的用法就是直接用 lint-staged，不需要额外依赖。它的配置文件可以写在 package.json 里，也可以单独放在 .lintstagedrc 文件中。比如：

// package.json
{
  "lint-staged": {
    "*.js": ["eslint --fix", "prettier --write"]
  }
}

这种方案的优点是配置简单，上手快，特别适合小型项目。但我个人不太推荐单独使用，因为每次都需要手动去执行命令，比如这样：

npx lint-staged

问题就出在这里：人总是会忘记。尤其是团队开发时，有人提交代码前忘记跑 lint-staged，代码质量就没法保证了。我之前在一个小项目里试过这个方案，结果就是时不时有人提交了不符合规范的代码，最后还是得回退重来。

方案二：lint-staged + husky

第二个方案是我最喜欢的，也是目前用得最多的：把 lint-staged 和 husky 结合起来。具体来说，就是用 husky 在 git 的 pre-commit 钩子里自动触发 lint-staged。

首先安装依赖：

npm install lint-staged husky --save-dev

然后初始化 husky：

npx husky install

接着添加一个 pre-commit 钩子：

npx husky add .husky/pre-commit "npx lint-staged"

最后，确保你的 lint-staged 配置没问题：

// .lintstagedrc
{
  "*.js": ["eslint --fix", "prettier --write", "git add"]
}

这个方案最大的好处是自动化程度高。只要配置好了，开发者几乎不用操心，提交代码时它会自动格式化和检查。而且因为 husky 已经成为事实上的标准工具，社区文档和解决方案都很成熟，踩坑的概率小了很多。

不过也有缺点，主要是性能问题。如果你的项目很大，或者 lint 规则很复杂，每次提交代码可能会卡几秒钟。我之前在一个老项目里遇到过这种情况，最后是通过缩小 lint 范围解决了——只对 staged 文件做检查。

方案三：自定义脚本

最后一个方案是完全自己写脚本，绕开 lint-staged。比如你可以写一个简单的 Node.js 脚本来处理：

// scripts/lint.js
const { execSync } = require('child_process');
const { getStagedFiles } = require('./utils');

const files = getStagedFiles();
if (files.length === 0) {
  console.log('No staged files found.');
  process.exit(0);
}

try {
  execSync(eslint --fix ${files.join(' ')}, { stdio: 'inherit' });
  execSync(prettier --write ${files.join(' ')}, { stdio: 'inherit' });
  console.log('Linting and formatting completed.');
} catch (error) {
  console.error('Linting failed. Please fix the issues before committing.');
  process.exit(1);
}

这个方案的好处是灵活性最高，你可以完全掌控整个流程，甚至可以根据项目需求定制一些特殊规则。但说实话，我不太喜欢这个方案，因为它需要你投入更多时间去维护。尤其是在多人协作的项目里，别人可能看不懂你的脚本逻辑，后期维护成本会很高。

还有个坑需要注意：自己写的脚本容易遗漏边界情况。比如我之前写的一个脚本，忘记处理空文件列表的情况，结果导致 git commit 一直失败，折腾了半天才发现问题。

我的选型逻辑

综合来看，我的选型逻辑其实很简单：看场景，选最适合的。

• 如果是个人小项目，或者团队成员技术能力参差不齐，我会选择 lint-staged + husky。这个方案虽然不是性能最优，但胜在稳定可靠，不容易出问题。
• 如果是一个需要高度定制化的项目，比如有特殊的代码检查规则，或者对性能要求特别高的大型项目，我会考虑自定义脚本。
• 至于纯 lint-staged，我觉得它更适合快速原型开发，或者那种“临时起意”的小工具项目。

这里再补充一点踩坑提醒：如果你选择了 lint-staged + husky 的方案，记得一定要定期更新依赖。我之前在一个项目里因为 husky 版本太旧，导致 pre-commit 钩子失效，差点酿成大祸。后来改成最新版的 husky（v7+），问题才解决。

性能对比：差距比我想象的大

最后说说性能问题。为了验证不同方案的实际表现，我特意在一个包含 500 个 JS 文件的项目里做了测试：

• 纯 lint-staged：平均耗时 3 秒左右。
• lint-staged + husky：平均耗时 4-5 秒。
• 自定义脚本：平均耗时 2-3 秒。

从数据上看，自定义脚本确实最快，但这点性能提升在我看来并不值得牺牲稳定性和可维护性。而 lint-staged + husky 的 1 秒额外开销，在日常开发中是可以接受的。

总结

以上是我个人对 lint-staged 不同方案的完整讲解，有更优的实现方式欢迎评论区交流。总的来说，lint-staged + husky 是我的首选，它在易用性和性能之间找到了一个不错的平衡点。当然，选型还是要看具体场景，没有绝对的最优解。

最后提醒一下：无论选哪种方案，记得定期检查配置文件是否还符合当前项目的实际需求。毕竟工具是为人服务的，别让工具反客为主。