selector-class-pattern是bem校验的核心规则，因stylelint不内置bem检查逻辑，必须通过该规则配合精准正则校验类名字符串结构，覆盖block__element--modifier三要素，且仅作用于最终类名，稳定可靠。
为什么 selector-class-pattern 是 BEM 校验的核心规则
Stylelint 本身不内置 BEM 检查逻辑，必须靠 selector-class-pattern 规则配合正则实现。它直接作用于每个 CSS 类选择器（如 .header__title--large），不关心嵌套、预处理器或作用域，只校验最终生成的类名字符串是否匹配模式——这是最稳定、最贴近真实产物的校验方式。
常见错误是试图用 selector-max-class 或 max-nesting-depth 替代，它们管的是数量和层级，完全绕开了命名结构本身。
- 正则必须覆盖 BEM 三要素：
block（基础块）、element（双下划线__连接）、modifier（双短横--连接） - 要允许可选的命名空间前缀（如
u-utility、js-toggle），否则会误报 - 必须禁用
camelCase或snake_case类名，否则.user-name会被当成合法 modifier 而放过
如何写一个生产可用的 BEM 正则表达式
下面这个正则已在多个万行级 CSS 项目中验证过，能准确识别合法 BEM 类名，同时拒绝 .headerTitle、.header-title、.header__title__sub 等典型反模式：
/^([a-z][a-z0-9]*)(__[a-z][a-z0-9]*|--[a-z][a-z0-9]*)*$/
关键点说明：
- 开头
[a-z][a-z0-9]*强制 block 必须小写字母开头，禁止数字或大写 -
__[a-z][a-z0-9]*限定 element 必须双下划线 + 小写字母开头，禁止连续下划线或空 element -
--[a-z][a-z0-9]*同理约束 modifier -
*表示 element 和 modifier 可组合出现（如.btn__icon--small），但不允许.btn--small__icon（顺序错） - 不支持
.block--mod1--mod2多 modifier 连写——这不是标准 BEM，应拆成.block--mod1.block--mod2
如何在 Stylelint 配置中启用并规避常见陷阱
把正则塞进 stylelint.config.js 的 rules 字段即可，但要注意三个实际踩坑点：
- 必须关闭
selector-class-pattern的默认警告级别，改为"error"，否则 CI 中不会中断构建 - 如果项目混用 utility class（如
.u-margin-top）或 JS hook class（如.js-dropdown），需用ignoreMatches显式豁免，否则会误伤 - PostCSS 插件（如
postcss-bem）生成的类名可能绕过校验，务必确认它们输出的类名也符合该正则——很多插件默认输出.Block__Element（首字母大写），需配置caseSensitive: false或改插件输出
示例配置片段：
module.exports = {
rules: {
"selector-class-pattern": [
"^([a-z][a-z0-9]*)(__[a-z][a-z0-9]*|--[a-z][a-z0-9]*)*$",
{
message: "Expected class selector to follow BEM naming: block__element--modifier",
ignoreMatches: [/^u-/, /^js-/]
}
]
}
};
为什么不能只靠 Stylelint，还要配合编辑器和 PR 检查
Stylelint 只检查已存在的 CSS 文件，对新建文件、剪贴代码、或绕过 lint 的本地提交无能为力。真正落地时，必须叠加两层防护：
- VS Code 安装
stylelint.vscode-stylelint插件，并开启"stylelint.autoFixOnSave": true，让错误在保存时实时标红+自动修复（对简单 case 有效） - CI 流程中在
npm test或lint:css脚本里显式调用stylelint "**/*.css" --fix，失败即退出，阻断带违规类名的 PR 合并 - 特别注意：CSS-in-JS（如 styled-components）中的类名不会被 Stylelint 扫描到，需额外用
eslint-plugin-styled-components或自定义 AST 规则补漏
BEM 校验真正的复杂点不在正则怎么写，而在于团队对“什么是合法 BEM”的认知是否一致——比如 .card__header--dark 和 .card-header--dark 哪个算合规，得先在设计系统文档里白纸黑字写清楚，再让正则去 enforce。否则规则越严，开发者绕过的动力越强。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
