Stylelint能解决CSS语法错误、风格不统一等问题，通过配置规则实现团队代码规范。它可检查无效属性、统一缩进与单位、规范命名，并集成到开发流程中，提升代码质量与团队协作效率。
Stylelint，说白了，就是CSS世界的‘语法警察’和‘风格管家’。它能自动检查你的样式代码，找出那些不符合规范、可能导致问题或者纯粹是风格不统一的地方，并给你反馈，让你的CSS代码保持整洁、一致和健壮。在我个人看来，它在提升前端项目可维护性和团队协作效率方面，简直是不可或缺的工具。
安装这玩意儿，其实挺简单的，就几行命令的事。我通常用npm或者yarn，npm install stylelint stylelint-config-standard --save-dev 这样一敲，基础架子就搭起来了。stylelint-config-standard 这个包我个人觉得挺好用的，它包含了大部分我们日常开发会遇到的样式规范，省得我们从零开始写规则，那得多累啊。
配置是Stylelint的核心，也是最能体现你项目风格的地方。一个.stylelintrc.json文件，就像你给Stylelint下达的指令清单。最简单的就是extends一个现成的配置，比如刚才提到的stylelint-config-standard。但很多时候，我们会有自己的偏好，或者项目有特殊要求，这时候就得用到rules了。比如，我习惯用两个空格缩进，那就可以加一句"indentation": 2。有时候团队里有人喜欢用单引号，有人喜欢双引号，这种细节也能通过规则统一起来，避免一些不必要的争论，挺好的。
跑起来也很方便，命令行直接stylelint 'src/**/*.css'就能扫描你的项目了。我个人更喜欢把它集成到开发工作流里，比如VS Code装个Stylelint插件，边写边提示，那种即时反馈的感觉，能让你少犯很多低级错误。再高级点，可以结合Husky和lint-staged做pre-commit hook，提交代码前自动检查，不符合规范就直接给你拦下来，强制大家遵守规则，这在团队协作里简直是神器。
立即学习“前端免费学习笔记（深入）”；
Stylelint能帮我解决哪些常见的CSS代码问题？
说实话，Stylelint最让我觉得有价值的地方，就是它能把那些我们平时容易忽略、或者觉得‘差不多就行’的CSS小毛病给揪出来，这直接提升了代码的质量。我遇到过不少情况，比如团队成员手滑，把margin-left写成了margn-left，或者颜色值写成了无效的#FG0000，这些低级错误Stylelint都能及时发现并报错，避免了样式渲染异常。
更深层次一点，它还能强制统一代码风格。比如说，我之前在一个项目里，有的人喜欢用4个空格缩进，有的人用2个，甚至还有人混着用tab，导致代码看起来乱七八糟。Stylelint通过indentation规则就能把这些问题统一掉。还有像CSS属性的顺序，比如position、display、width、height，再到margin、padding，最后是color、background等等，虽然没有绝对的标准，但一旦团队内部约定了，Stylelint就能确保每个人都遵守，这样代码的可读性会大大提升。
再举个例子，单位的使用。有的项目要求所有尺寸都用rem，有的可能混合px和em，Stylelint的unit-allowed-list规则就能限制开发者只能使用特定单位，避免了单位混用带来的计算困扰。对于一些命名规范，比如BEM（块、元素、修饰符）或者驼峰命名，Stylelint也能通过selector-class-pattern这样的规则来强制执行，让选择器命名更具语义化和可预测性。这些点点滴滴的规范，最终汇聚成一股力量，让整个项目的CSS代码库变得更加健壮和易于维护。
如何根据我的项目需求定制Stylelint配置？
定制Stylelint配置是让它真正为你项目服务、发挥最大价值的关键一步。每个团队、每个项目都有自己的‘脾气’和约定，所以直接拿一套通用的配置可能不太够用。定制通常围绕着.stylelintrc.json这个文件展开。
最基础的定制就是通过extends字段来继承一些社区里成熟的配置，比如stylelint-config-standard或者stylelint-config-recommended。这些配置已经包含了大量普遍认可的规范，能让你省去很多从零开始的麻烦。我个人倾向于先继承一个，然后在此基础上进行微调。
微调就是通过rules字段来覆盖或新增规则。比如，你可能觉得默认配置的缩进是4个空格，但你们团队偏爱2个空格，那就可以这样写："indentation": 2。Stylelint的规则非常丰富，几乎涵盖了CSS的方方面面。你可以设置规则的级别，比如"color-no-invalid-hex": "error"会直接报错，而"declaration-property-unit-allowed-list": ["rem", "em"]则会限制属性单位。有时候，我们还会用到plugins，比如如果你在使用SCSS或Less，就需要安装并配置相应的插件，让Stylelint能正确解析这些预处理器语法。
别忘了ignoreFiles这个选项，它能让你指定哪些文件或目录不需要Stylelint检查，比如node_modules目录下的第三方库或者一些自动生成的压缩文件，这样可以大大提升检查效率，也能避免对不属于自己维护的代码进行不必要的干预。
{
"extends": "stylelint-config-standard",
"plugins": [
"stylelint-scss"
],
"rules": {
"indentation": 2,
"color-hex-case": "lower",
"selector-class-pattern": "^[a-z][a-zA-Z0-9]+$", // 简单的驼峰命名示例
"unit-allowed-list": ["px", "em", "rem", "%", "vw", "vh"],
"scss/at-extend-no-missing-placeholder": true, // SCSS插件规则
"max-empty-lines": 1 // 限制空行数量
},
"ignoreFiles": [
"**/node_modules/**",
"**/*.min.css",
"dist/**/*.css"
]
}通过这样的配置，你的Stylelint就能像量身定制的西装一样，完美契合项目的风格和需求。
Stylelint在大型团队协作中扮演什么角色？
我经历过那种没有Stylelint的团队，那代码风格真是‘百花齐放’，每个人都有自己的写法，维护起来简直是噩梦。当一个新成员加入时，他得花大量时间去适应各种不同的写法，代码评审的时候，也总是纠结于缩进、命名这些小问题，效率非常低下。
Stylelint在大型团队协作中，简直就是统一战线的利器。它能确保所有开发者都遵循一套共同的样式规范，不管谁写的代码，看起来都像是同一个人写出来的。这种高度的一致性，大大降低了代码的认知负荷，让团队成员能把更多精力放在业务逻辑和功能实现上，而不是纠结于格式问题。
它还能作为团队的“守门员”。通过集成到Git的pre-commit hook，Stylelint可以在代码提交前自动检查并修复（如果配置了自动修复）样式问题。如果代码不符合规范，提交就会被阻止，强制开发者在提交前解决这些问题。这不仅保证了进入代码库的代码质量，也减轻了代码评审者的负担，他们可以专注于更复杂的逻辑和架构问题，而不是去指出每一个缺少分号的错误。
对于新入职的团队成员来说，Stylelint也是一个很好的“导师”。它能通过即时反馈，帮助新人快速了解并适应团队的编码风格，减少了口头传授和反复修改的成本。长远来看，Stylelint的存在，能有效遏制技术债的累积，让项目的CSS代码库始终保持健康、可维护的状态，这对于大型项目和长期迭代来说，价值是无法估量的。它不再仅仅是一个工具，更像是一种团队文化和质量保障机制的体现。
