IE8及更早版本不支持:nth-child()、:not()（多参数）、[attr^="val"]等选择器，::before仅认: before；整条规则被忽略，无降级；Selectivizr可JS模拟补全，需配合jQuery等库及polyfill。
哪些CSS选择器在旧浏览器里根本不起作用
IE8及更早版本不支持 :nth-child()、:not()（只支持单参数如 :not(div)，不支持 :not(.foo, .bar)）、[attr^="val"] 等属性选择器，::before 伪元素写法也只认单冒号 :before。这不是“渲染不一致”，是直接被忽略——规则整条丢弃，连降级机会都没有。
常见错误现象：document.querySelectorAll('.item:not(.disabled)') 在IE8里抛出 SyntaxError: Invalid character；用 input[type="number"] 做样式隔离，结果IE9以下所有 <input> 都没生效。
- 别指望CSS解析器做容错：遇到不认识的选择器，整条规则被跳过，不会尝试匹配其中一部分
- 检查目标环境时，重点不是“有没有CSS3”，而是查具体选择器的 caniuse 条目，按浏览器版本逐条核对
- 如果项目必须支持IE8，
:not()和复合属性选择器基本得全手写JS补丁，CSS层没法优雅降级
用Selectivizr处理IE6–IE8的选择器兼容问题
Selectivizr 是唯一还在维护、且真正能补全 :nth-child()、:first-of-type、[data-foo] 等选择器的JS库。它不改写CSS，而是在DOM加载后，用JS模拟匹配逻辑，再给匹配到的元素加临时类名（比如 .selectivizr-nth-child-2），让你的样式靠类名兜底。
使用场景：老系统改造、政府/企业内网项目，明确要求IE8兼容但又不能重写全部CSS。
立即学习“前端免费学习笔记（深入）”；
- 必须配合一个JS库一起用：Selectivizr本身不实现
querySelectorAll，依赖jQuery、dojo或原生Element.matches（IE8没有，所以你得带一个polyfill） - 引入顺序很关键：先载入基础JS库（如
jquery.min.js），再载入selectivizr-min.js，最后才载入CSS文件 - 它只作用于已存在的DOM，动态插入的元素需要手动调用
selectivizr.refresh()，否则新节点不触发匹配
为什么不用CSS Polyfill做现代选择器转换
像 cssnext 或 PostCSS 的 postcss-selector-matches 插件，本质是构建时把 :is()、:where() 编译成冗长的兼容写法。但这类转换有硬伤：生成的选择器可能爆炸式膨胀，且无法覆盖运行时逻辑（比如 :has() 依赖DOM结构变化）。
性能影响比想象中大：一个 :is(.btn, .link, .nav-item) 编译后变成三条独立规则；:has(+ .error) 根本没法静态展开，所有PostCSS方案都直接跳过或报错。
- 构建工具链里开 selector polyfill，等于默认放弃
:has()、:focus-visible等真正需要运行时判断的选择器 - 编译后的CSS体积增长不可控，尤其在用大量
:is()组合时，gzip后仍可能多出20%+字节 - 如果你的项目已用Webpack/Vite，别试图用插件“自动修复”选择器——不如在代码审查时卡住非标写法，明确标注哪些组件只支持现代浏览器
真正该做的：用特性检测代替浏览器检测
与其纠结“IE8要不要加Selectivizr”，不如在JS里测 document.querySelector(':nth-child(1)') 是否抛错。失败就加载polyfill，成功就跳过——这样既避开UA欺骗问题，也能让Edge 12+、Safari 3.1等早期WebKit用户正确获益。
容易被忽略的一点：CSS选择器兼容性不是独立问题，它和 classList、matches()、CSS.supports() 等API强绑定。单独补一个选择器，其他地方照样崩。
- 检测代码要放在
尽早执行，避免FOUC或样式错乱 - 不要用
navigator.userAgent判断IE：Edge也带MSIE字段，IE11又伪装成Mozilla，误判率极高 - 如果项目里已有
core-js，注意它不包含选择器polyfill——CSS部分永远要单独处理
