答案：定制Stylelint规则需安装工具并创建配置文件，通过extends继承标准配置，在rules中覆盖或新增规则以适配团队规范，结合插件支持SCSS等语法，集成Prettier避免格式冲突，并将共享配置发布为npm包实现多项目统一，同时用注释文档化规则变更。
Stylelint的规则定制与使用，核心在于通过配置其内置或自定义规则，确保团队CSS代码风格统一、避免潜在错误，并提升代码可维护性。这不仅仅是工具的运用，更是团队协作效率与项目质量的保障，它能让你的CSS代码库从“能用”走向“好用”和“易于维护”。
解决方案
要有效地定制和使用Stylelint规则，我们通常会经历几个关键步骤。这套流程我个人觉得是比较顺手且高效的。
首先是安装。你需要将Stylelint及其配套配置安装到项目中。通常我们会选择一个标准配置作为起点，比如
stylelint-config-standard。
npm install stylelint stylelint-config-standard --save-dev # 或者 yarn add stylelint stylelint-config-standard --dev
接着，是创建配置文件。在项目根目录创建
.stylelintrc.json或
stylelint.config.js文件。我更倾向于
.json，因为它更简洁，但如果需要更复杂的逻辑，
.js文件会更灵活。
立即学习“前端免费学习笔记（深入）”；
// .stylelintrc.json 示例
{
"extends": ["stylelint-config-standard"],
"rules": {
// 覆盖或添加规则
"indentation": 2, // 强制缩进为2个空格
"color-hex-case": "lower", // 强制十六进制颜色为小写
"selector-class-pattern": "^[a-z][a-zA-Z0-9]+$", // 强制类名使用小驼峰
"max-empty-lines": 1, // 限制最大空行数为1
"no-descending-specificity": null // 关闭关于选择器权重递减的检查，有时这会过于严格
}
}这里
extends字段引入了
stylelint-config-standard的所有规则。然后，
rules字段就是我们进行定制的核心区域。你可以覆盖
standard配置中的规则，比如将
indentation从默认的4个空格改为2个，或者添加一些
standard中没有的规则，比如
selector-class-pattern来规范类名。有时候，某些规则在特定项目中可能显得过于严格或不适用，这时可以直接将其值设为
null来禁用。
配置完成后，就可以运行Stylelint了。最直接的方式是通过命令行：
npx stylelint "**/*.css" # 或者检查 SCSS 文件 npx stylelint "**/*.scss" # 自动修复部分可修复的问题 npx stylelint "**/*.css" --fix
在实际开发中，我通常会将其集成到项目的构建流程中，比如Webpack的
stylelint-webpack-plugin，或者在Git hooks中通过
lint-staged和
husky在提交前自动检查，这能有效避免不符合规范的代码进入版本库。
为什么我们需要定制Stylelint规则，仅仅使用默认配置不够吗？
我个人觉得，仅仅依赖Stylelint的默认配置，就像是穿着一套均码的西装去参加一场量身定制的晚宴，虽然能穿，但总觉得哪里不对劲，不够合身，也无法展现出独特的风格。Stylelint的默认配置，比如
stylelint-config-standard，确实是一个非常棒的起点，它涵盖了大多数通用的CSS最佳实践和风格规范。但问题在于，“通用”往往意味着它无法完全贴合特定项目的“个性化”需求。
每个项目都有其独特的背景和约定。比如，有的团队偏爱BEM命名法，有的则采用CSS Modules，甚至有些项目会大量使用Tailwind CSS这样的工具类。默认配置往往不会对这些特定的命名约定或工具链有深入的感知和检查。再比如，你可能在项目中使用了SCSS或Less，这些预处理器引入了变量、混合宏、嵌套等特性，默认的CSS规则并不能完全覆盖这些语法的潜在问题。
我的经验告诉我，如果不进行定制，Stylelint可能会出现两种情况：一是它会报错一些我们团队约定为“正确”的代码，成为开发者的负担和噪音；二是它会放过一些我们团队认为“错误”的代码，导致代码风格逐渐发散，最终失去其作为代码质量保障工具的价值。定制规则，就是让Stylelint真正成为团队的“守门员”，而不是一个无关痛痒的旁观者。它确保了工具的输出与团队的实际需求和编码习惯高度一致，从而真正提升代码的可维护性和团队协作效率。
如何高效地管理和维护Stylelint配置，避免配置地狱？
管理和维护Stylelint配置，尤其是对于大型项目或多项目并行的场景，确实是一个需要策略的事情。我曾经也掉进过“配置地狱”的坑，一个
.stylelintrc文件长达数百行，每次修改都心惊胆战。我的心得是，要像管理代码一样管理配置。
一个非常有效的策略是分层配置。你可以从一个基础的、通用的配置开始（比如
stylelint-config-standard），然后在此基础上，为不同的预处理器（如
stylelint-config-standard-scss）添加一层，最后再叠加项目或团队特有的规则。通过
extends数组，你可以像搭积木一样构建配置：
// .stylelintrc.json
{
"extends": [
"stylelint-config-standard",
"stylelint-config-standard-scss", // 如果使用 SCSS
"stylelint-config-prettier" // 推荐与 Prettier 配合使用
],
"rules": {
// 项目特有规则
"scss/at-extend-no-missing-placeholder": true,
"selector-class-pattern": "^[a-z][a-zA-Z0-9-]+$", // 更宽松的类名模式
"property-no-unknown": [
true,
{
"ignoreProperties": ["-webkit-box-orient"] // 忽略特定私有前缀属性
}
]
}
}这里
stylelint-config-prettier的引入尤其重要。我强烈建议将格式化的工作交给Prettier，而Stylelint则专注于代码风格和潜在错误。这样可以避免Stylelint和Prettier在格式化规则上的冲突，大大简化Stylelint的配置，让它更纯粹。
对于多项目或Monorepo场景，可以考虑发布一个共享的Stylelint配置包到npm。这样，所有项目都可以
extends这个包，确保了整个组织内代码风格的一致性。当需要更新规则时，只需要更新这个共享包，所有依赖的项目都能同步更新，这比手动同步每个项目的配置要高效得多。
最后，别忘了文档化。在配置文件中添加注释，解释为什么某些规则被启用、禁用或修改。这对于新加入的团队成员理解配置意图，以及未来回顾和调整配置都非常有帮助。配置不是一成不变的，随着项目演进和团队习惯的改变，定期回顾和调整配置也是维护其生命力的关键。
Stylelint插件在规则定制中扮演什么角色，如何使用它们？
Stylelint插件在规则定制中扮演着非常重要的角色，它们是Stylelint核心功能之外的“扩展包”，极大地增强了Stylelint的灵活性和适用范围。如果说核心规则是Stylelint的骨架，那么插件就是其肌肉和神经，让它能够处理更复杂、更具体的场景。
插件的主要作用是：
-
支持非标准CSS语法：例如，如果你在使用SCSS或Less，它们有自己独特的语法特性（变量、混合宏、嵌套等），Stylelint核心规则无法很好地理解和检查这些。
stylelint-scss
或stylelint-less
这样的插件就能提供针对这些预处理器语法的规则。 -
实现特定功能或最佳实践：有些规则并非CSS标准的一部分，但却是业界公认的最佳实践，或者某个团队的特定要求。例如，
stylelint-order
插件可以强制CSS属性的声明顺序，stylelint-a11y
插件则专注于辅助功能（accessibility）相关的CSS规则。 - 集成其他工具或理念：有些插件可能旨在与其他工具或设计理念协同工作，提供更深层次的集成检查。
使用Stylelint插件的流程通常很直接：
1. 安装插件： 通过npm或yarn安装你需要的插件。例如，安装
stylelint-scss和
stylelint-order：
npm install stylelint-scss stylelint-order --save-dev
2. 在.stylelintrc.json
中引入插件：
在配置文件的
plugins数组中添加插件的名称。
// .stylelintrc.json
{
"plugins": [
"stylelint-scss",
"stylelint-order"
],
"extends": [
"stylelint-config-standard",
"stylelint-config-standard-scss" // 推荐在引入 stylelint-scss 后也扩展其配置
],
"rules": {
// SCSS 相关的规则
"scss/dollar-variable-pattern": "^[a-z][a-zA-Z0-9]+$", // 强制 SCSS 变量使用小驼峰
"scss/at-import-partial-extension": "never", // 强制 @import 不带文件扩展名
// 属性排序规则 (来自 stylelint-order)
"order/order": [
"custom-properties",
"dollar-variables",
"declarations",
"at-rules",
"rules"
],
"order/properties-order": [
"position",
"z-index",
"top",
"right",
"bottom",
"left",
"display",
"flex",
"flex-direction",
"justify-content",
"align-items",
"width",
"height",
"margin",
"padding",
"color",
"font-size",
"background"
]
}
}在这个例子中，
plugins数组告诉Stylelint加载
stylelint-scss和
stylelint-order这两个插件。然后，在
rules字段中，你就可以像配置内置规则一样，配置这些插件提供的规则了。注意，插件提供的规则通常会有一个命名空间前缀（比如
scss/或
order/），这有助于区分它们。
我个人觉得，插件是Stylelint真正强大的地方。如果没有它们，很多特定场景的检查就无从谈起。比如，我曾经在一个大型SCSS项目中，如果没有
stylelint-scss来检查变量、混合宏的命名和使用，代码质量恐怕会一团糟。合理利用插件，能让Stylelint的检查能力达到一个新的高度，真正做到“量体裁衣”。
