属性选择器（如[class^="icon-"]）比类选择器（.icon-home）慢，因其无法利用class哈希索引，需对每个元素做字符串前缀扫描，节点超1000时样式计算耗时翻倍。
为什么 [class^="icon-"] 比 .icon-home 慢得多
浏览器对 class 名有哈希索引，.icon-home 是 O(1) 查找；而 [class^="icon-"] 无法利用该索引，每次都要对每个元素的 class 属性做字符串前缀扫描——DOM 节点超 1000 个时，样式计算耗时可能翻倍。
常见错误现象：DevTools → Performance 面板 → Recalculate Style 占比突增，尤其在首屏渲染或动态插入节点后；Coverage 面板 显示该规则实际命中极少，但开销极高。
- 属性选择器在
:hover、:focus等交互状态中会高频重算，比静态规则更敏感 -
[data-role="button"]比[class*="btn"]稍好（值更固定），但仍不如单类名 - Sass/Less 中写
&[data-state="active"]会编译出同样低效的选择器，别被语法糖骗了
* { box-sizing: border-box; } 看似简洁，实则最危险的写法之一
它不只匹配 visible 元素：script、meta、comment、svg 节点全被强制参与匹配。Chrome DevTools 的 Performance 面板里能看到大量 “Style invalidation” 和 “Style recalculation” 任务堆积。
更隐蔽的问题是：在 Web Components 或 Shadow DOM 场景下，* 会跨边界触发封装检查，开销成倍放大。
立即学习“前端免费学习笔记（深入）”；
- 替代方案不是“不用”，而是“收窄作用域”：比如只对
article *或.content *使用 - 现代项目应直接在
html或:where(html)上设box-sizing，再靠继承传递 - 若必须全局重置，用显式列举：
html, body, div, p, span, h1, h2, h3, ul, ol, li, a, button, input, textarea
深层嵌套 + 属性选择器组合（如 .card [data-type="title"]）是性能双杀
浏览器先从右往左找所有 [data-type="title"]，再逐层向上验证是否在 .card 内——两重低效叠加：属性扫描 + 多层回溯。实测在低端 Android 设备上，这类组合比 .card__title 慢 4 倍以上。
容易被忽略的场景：CSS-in-JS 库（如 Emotion、Styled Components）自动生成的属性选择器，或构建工具注入的 data-styled 类似逻辑。
- 优先用 BEM 类名替代：把
.card [data-type="title"]改为.card__title - 若需保留数据驱动语义，改用
[data-component="card"] [data-role="title"]，至少避免 class 层级依赖 - 构建后快速排查：
grep -r "\[.*\] .* \." dist/可定位所有含空格+属性的组合
哪些“看起来安全”的属性选择器其实也危险
不是只有 [class^="icon-"] 才有问题。[type="submit"]、[for]、[aria-*] 这些看似语义清晰的选择器，在高密度表单或复杂组件中一样会拖慢匹配。
伪类与属性混用更致命：:not(.disabled) [type="button"] 会让浏览器放弃所有优化路径，强制全量扫描并逐个过滤。
-
input[type="text"]应统一替换为.form-input，把类型判断交给类名契约 -
[aria-expanded="true"]在可折叠菜单中高频变更，建议配合will-change: attr(aria-expanded)提示渲染器，但更治本的是加.is-expanded类 - 慎用
@import引入含属性选择器的 CSS 文件——它会阻塞并行解析，让首屏等待时间雪上加霜
真正难优化的，往往不是某条孤立规则，而是属性选择器嵌在 4 层以上后代链里、又被 JS 频繁 toggle 的那个 data- 属性——它既触发样式重算，又引发布局抖动，还绕过了浏览器的大多数缓存机制。
