结论是：应使用 .stylelintrc.js 而非 JSON，优先启用 property-no-unknown、length-zero-no-unit、declaration-block-no-duplicate-properties 三条规则，可拦截90%低级 Bug；因 JS 配置支持注释、环境判断、动态导入和变量复用，而 JSON 无法满足实际工程需求。
直接说结论：用 .stylelintrc.js 而不是 JSON，规则从 property-no-unknown、length-zero-no-unit、declaration-block-no-duplicate-properties 这三条起步，别一上来就 extend 全量配置——90% 的低级 Bug 就靠它们拦住。
为什么必须选 .stylelintrc.js 而不是 JSON
JSON 看似简单，但实际开发中很快会卡死：没法写注释说明某条规则为什么开/关，不能根据环境（如是否在组件库项目里）动态开关 declaration-no-important，更没法 require 团队共享的规则包或复用变量。而 JS 文件导出一个对象就行，比如：
module.exports = {
extends: ['@frontlint/stylelint'],
ignoreFiles: ['**/node_modules/**', '**/dist/**'],
rules: {
'color-hex-case': 'lower',
'selector-class-pattern': '^([a-z][a-z0-9]*)(-[a-z0-9]+)*$'
}
};
常见错误是只写 module.exports = {} 却没填 rules 或 extends 字段，导致整个配置静默失效；还有人把 overrides 写进去了，却忘了配 files 字段，结果 SCSS 文件压根不被扫到。
property-no-unknown 为什么排第一位
它能立刻捕获 dispay: flex、backgroud-color: #fff 这类拼写错误，成本为零，收益极高。但要注意两点：
立即学习“前端免费学习笔记（深入）”；
- 如果你用了 CSS-in-JS 或自定义属性（如
--primary-color），得配合custom-property-pattern规则，否则--foo会被当成未知属性报错 - 某些 PostCSS 插件生成的属性（如
-webkit-line-clamp）需要显式加进property-unknown-ignore-regex，不然 CI 里总飘红 - 该规则默认不检查自定义语法（如 SCSS 变量
$color），要校验变量名得靠scss/dollar-variable-pattern插件
SCSS/Less 文件怎么正确启用 Stylelint
命令行跑 stylelint **/*.scss 成功 ≠ 编辑器里有提示。VS Code 和 WebStorm 都默认只认 .css，必须手动干预：
- VS Code 的
settings.json里，stylelint.validate必须显式列出"scss"，不能只写["css"] - WebStorm 中，
Stylelint package路径必须指向node_modules/stylelint（不是.bin/stylelint），且Run for files要填**/*.css;**/*.scss，改完必须重启 IDE - 如果项目混用多种预处理器，用
overrides比全局 extend 更安全，例如对**/*.less关掉scss/at-import-partial-extension类规则，避免误报
CI 里 Stylelint 报错但本地不报，通常卡在哪
最常被忽略的是 Node 版本和 stylelint 版本不一致。v16+ 的 stylelint 默认不解析 .scss，必须装 stylelint-scss 并在配置里加 plugins: ['stylelint-scss']；而本地开发可能用了 pnpm 或 nvm 切了旧版 Node，导致 CLI 行为不一致。另一个隐形坑是 .stylelintignore 里写了 !src/**/*.scss，但路径匹配依赖 node-ignore，! 否定规则必须写在对应 ignore 规则之后，顺序错了就白写。
