:is()一写错就整条规则消失，因浏览器遇无效选择器会丢弃整个规则而非仅忽略错误项，旧版safari及双核浏览器尤为明显；应只放已验证的安全选择器、避免混用、构建时展开，并谨慎评估维护成本。
为什么:is()一写错就整条规则消失？
因为浏览器遇到无效选择器（比如拼错的.btn-prmary、不支持的:has()或非法语法.a::before）时，会直接丢弃整个:is()规则——不是忽略错误项，而是整行 CSS 归零。旧版 Safari 15.2–15.3 和部分双核浏览器（如 360、QQ 浏览器）尤其典型，DevTools 的 Styles 面板里根本看不到这条规则。
常见诱因包括：
- 末尾多逗号：
:is(.a, .b, ) - 混入伪元素：
:is(h1::after, h2) - 使用未被支持的伪类：
:is(:has(p), h2)（Safari 15.4 才支持:has） - 属性选择器含特殊字符但未转义：
:is([data-role="modal-header"])中引号不匹配
怎么写才能让:is()不因一个错误全盘崩溃？
核心原则是：只放已验证、全环境安全的选择器，且类型尽量统一。不要为了“看起来简洁”塞进未经测试的变体。
稳妥做法：
- 全部用类名：
:is(.title, .heading, .section-title)（权重一致，无兼容风险） - 全部用标签：
:is(h1, h2, h3)（语义清晰，各浏览器都认） - 避免混用：
:is(.btn, button[type="submit"], #main-cta)—— ID 选择器拉高权重，还可能在旧 Safari 因#main-cta不存在而整条失效 - 子选择器需完整验证：
:is(.card > h2, .post > h2)比:is(.card h2, .post h2)更可控（前者明确层级，后者易受嵌套干扰）
构建时展开:is()比运行时回退更可靠
依赖 :where() 或 UA 检测做运行时 fallback 是危险的：:where() 权重归零，覆盖不了已有样式；UA 字符串在双核浏览器里不可信。真正稳定的方案是构建阶段展开。
推荐操作：
- 用 PostCSS 插件（如
postcss-is-pseudo）把:is(h1, h2, h3)编译为h1, h2, h3 - CI/CD 中加入真机截图比对，重点检查 Safari 15.3 及双核浏览器下的标题、按钮等关键区域
- 展开后仍要人工核对 specificity：原
:is(.a, div#b)展开为.a, div#b，权重差异保留，不能假设它“自动降权”
哪些场景下:is()反而增加维护成本？
当你要单独调整其中某一项时，:is() 就成了障碍。比如写了 :is(h1, h2, h3) { line-height: 1.2; }，之后想给 h2 单独加 font-size: 1.5em，结果会被前面那条规则覆盖——因为 :is(h1, h2, h3) 和 h2 权重相同，后声明者胜出，但你本意是增强而非覆盖。
这类情况更适合保留手动分写，或改用 CSS 自定义属性解耦：
:root {
--heading-line-height: 1.2;
}
h1, h2, h3 { line-height: var(--heading-line-height); }
h2 { font-size: 1.5em; }
真正容易被忽略的是：容错性不等于“写得随意”，而是靠验证 + 展开 + 分离控制逻辑来共同实现。一个没经过构建验证的 :is()，在生产环境里可能比手写逗号列表更脆弱。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
