优先用 .stylelintrc.js，因支持注释、条件逻辑、动态规则、共享配置复用；JSON 不支持这些。需正确导出含 rules/extends 等字段的对象，用 overrides 按文件类型差异化配置，避免路径硬编码，推荐启用 property-no-unknown 等高频纠错规则。
Stylelint 配置文件怎么选：.stylelintrc.js 还是 .stylelintrc.json？
优先用 .stylelintrc.js。JSON 不支持注释、条件逻辑和动态规则（比如根据环境开关某条规则），而 JS 文件能直接 require 共享配置、复用变量，也方便做规则分组或按 CSS 预处理器类型差异化处理。
常见错误是把 rules 写在顶层对象里却忘了加 extends 或 plugins 字段，导致规则不生效；更隐蔽的是用了 overrides 却没配 files 匹配模式，结果 SCSS 文件根本没被校验。
- 必须导出一个对象，不能只写
module.exports = {...}就完事——要确保它有rules、extends等合法字段 - 如果项目混用 CSS/SCSS/Less，用
overrides分开配置，例如对**/*.scss启用stylelint-scss插件规则 - 避免在
rules里写死路径，改用ignoreFiles排除node_modules/**和构建产物目录
哪些规则最值得开：从易出 Bug 的场景倒推
别一上来就全开默认规则。先聚焦三类高频问题：属性拼写错误（如 dispay: flex）、单位缺失（margin: 10）、重复声明（同一选择器里两个 color）。
这些对应的核心规则是 property-no-unknown、length-zero-no-unit、declaration-block-no-duplicate-properties。它们开起来零成本，且能立刻拦截低级错误。
立即学习“前端免费学习笔记（深入）”；
-
color-no-invalid-hex能捕获#fg0000这类无效色值，比等上线后靠人眼发现快得多 -
declaration-block-trailing-semicolon设为"always"，避免因少个分号导致 IE 下整块样式失效 - 禁用
!important用declaration-no-important，但别全局禁——允许在覆盖第三方库样式时例外，可用/* stylelint-disable declaration-no-important */局部绕过
VS Code 里 Stylelint 不报错？检查这三处
本地编辑器不提示，90% 是插件链断了：要么 VS Code 没装 Stylelint 插件，要么插件没读到配置，要么配置里没启用 validate。
关键点在于 VS Code 的 settings.json 必须显式开启校验：
{
"stylelint.enable": true,
"stylelint.configFile": "./.stylelintrc.js",
"stylelint.validate": ["css", "postcss", "scss", "sass", "less"]
}
常见坑："stylelint.validate" 默认只含 css，加了 SCSS 却忘了加 scss；或者配置文件路径写成相对路径（如 ../.stylelintrc.js），而 VS Code 工作区根目录不是项目根目录。
- 运行
npx stylelint \"src/**/*.css\"命令行验证配置是否生效，排除编辑器干扰 - 插件版本要和项目中
stylelint版本兼容——v16+ 需搭配插件 v1.5.0+ - 若用 Prettier，必须装
stylelint-config-prettier关闭所有格式化规则，否则和 Prettier 冲突
CI 流程里怎么卡住不规范的 CSS 提交？
光本地提醒不够，得在 git push 或 CI 流水线里强制校验。推荐在 pre-commit 钩子里跑 stylelint，失败则中断提交。
用 husky + lint-staged 组合最稳：只检查暂存区里的 CSS/SCSS 文件，不扫全量，速度快，也不误伤别人代码。
- 在
package.json中配"lint-staged": {"*.{css,scss,less}": "stylelint --fix"} -
--fix参数能自动修复部分问题（如空格、分号），但别依赖它修逻辑错误 - CI 脚本里加
npx stylelint \"src/**/*.{css,scss,less}\" --max-warnings 0，让警告数超 0 就失败——避免团队把警告当空气
真正难的是统一认知：规则不是越严越好，而是谁改谁负责解释为什么关掉某条。每次调整配置，都得同步更新 README 里的「规则说明」章节，不然新人照着旧文档踩坑。
