Stylelint不能检测CSS逻辑错误，仅检查语法、格式和风格规范；它不分析样式是否生效、被覆盖或与HTML匹配，也不判断颜色对比度、响应式断点合理性等，真正暴露此类问题需依赖浏览器DevTools、Lighthouse或运行时JS检查。
display: flex 写在已被 display: none 覆盖的选择器里，或 z-index 在无定位上下文中失效，这类问题 Stylelint 完全不感知。
真正能暴露这类问题的，是浏览器 DevTools、CSS 覆盖率分析、Lighthouse 的无障碍/可访问性检测，或者运行时 JS 注入的样式健康检查（如 getComputedStyle 断言）。Stylelint 的定位很明确：它是静态代码检查器，不是运行时验证器。
为什么 stylelint --fix 不会修复“无效但合法”的 CSS？
Stylelint 的修复能力仅限于明确标记为 ✅ 的规则，例如：
-
color-hex-case：自动转成小写或大写 -
declaration-block-trailing-semicolon：补分号或删分号 -
indentation：调整缩进空格数
但像以下情况，它既不报错也不修复：
-
background-color: #fff; color: #fff;（文字不可见）→ 无对应规则，需用 axe 或 Lighthouse -
width: 100vw; padding: 20px;（实际溢出）→ 属于布局逻辑，非 Stylelint 范畴 -
@media (min-width: 768px) { @media (max-width: 992px) { ... } }（嵌套媒体查询）→ CSS 本身合法，Stylelint 不校验嵌套合理性
哪些“看起来像逻辑错误”的问题 Stylelint 确实能捕获？
它能识别部分因拼写、语法或结构导致的“伪逻辑错误”，本质仍是语法/规范层面：
立即学习“前端免费学习笔记（深入）”；
-
property-no-unknown：比如把text-algin当作text-align→ 报错，因为属性名不存在 -
no-invalid-position-at-import-rule：在@import后写了普通声明 → 违反 CSS 解析顺序 -
declaration-block-no-duplicate-properties：同一块内重复写color→ 可能掩盖意图，属结构冗余 -
no-empty-source：空的.foo {}块 → 不影响渲染，但大概率是误删内容的信号
这些不是“运行时逻辑”，而是“源码可信度”提示——它们存在，说明开发者可能疏忽了基础书写，值得人工复核。
想检查 CSS 是否真起作用？得换工具链
如果目标是验证样式逻辑（比如“这个按钮在移动端是否真的居中？”），必须跳出 Stylelint：
- 用 Puppeteer +
getComputedStyle写 E2E 断言，验证特定元素在特定视口下的计算值 - 用 Storybook + a11y 插件，检查颜色对比度、焦点顺序等可访问性逻辑
- 用 Chrome DevTools 的 “Coverage” 面板，看哪些 CSS 规则从未被匹配到（疑似冗余或 selector 错误）
- 用
css-tree或自定义 PostCSS 插件做 AST 分析，比如检测所有z-index是否都落在position: relative/absolute/fixed元素上
Stylelint 的配置文件里加再多规则，也填不了这个 gap。它的价值在于守住底线：让 CSS 源码干净、一致、可读；至于它“有没有效”，那是另一层工程问题。
