属性选择器本身性能良好，但深层嵌套、通配符匹配及高频更新场景会显著降低性能；应优先使用带索引的原生属性、避免宽泛选择器，并将data-属性逻辑前置为class。
属性选择器本身不慢，但组合方式会拖垮性能
纯 [type="text"] 或 [data-id] 这类简单属性选择器，现代浏览器解析开销极小，和 .class 基本持平。真正出问题的是嵌套层级深、匹配范围广的写法，比如 div[data-role="menu"] ul li a[title]:not([disabled]) —— 浏览器得反复回溯 DOM 树、逐个检查属性是否存在/值是否匹配，尤其在动态更新频繁的页面上，重排重绘压力会明显上升。
- 越靠右的选择器越关键：浏览器从右往左匹配，
a[title]是关键锚点，如果页面里有几千个<a>但只有几个带title，那还好；但如果title属性普遍存在，又叠加左侧复杂条件，就容易卡 - 避免在高频更新区域（如列表项、弹窗内容）使用
[style*="color"]这类含通配符的属性选择器，每次内联样式变更都会触发重新计算 -
[attr]（只判断存在）比[attr="val"]（精确匹配）略快，而[attr~="val"]和[attr|="val"]因需分词或前缀判断，开销更高
对比 class 与属性选择器的实际渲染耗时
用 Chrome DevTools 的 Rendering 面板 + FPS meter 实测：在 500 个同级 <input> 元素上分别应用 .input-text 和 [type="text"] 样式，强制重绘时，前者平均 layout 耗时约 0.8ms，后者约 1.2ms —— 差距微小；但若把选择器改成 form div * [type="text"]，layout 时间跳到 4.7ms 以上，且 JS 执行帧也出现抖动。
/* 快：明确、窄、靠右锚定 */
.button[data-loading="true"] { opacity: 0.6; }
<p>/<em> 慢：宽泛、多层、依赖通配符 </em>/
*:not(.skip) [data-tip]::before { content: attr(data-tip); }哪些属性选择器要特别小心
不是所有属性选择器都平等。浏览器对某些 HTML 原生属性（如 id、class、type）做了内部索引优化，而自定义 data- 属性和 SVG 属性（如 fill、stroke）通常无索引，匹配全靠遍历。
详细的 Three.js 3D 图形参考，涵盖场景设置、相机、几何体、材质、光照、动画、控制器、加载器、数学工具和调试。
-
[id]、[class]、[type]：有底层加速，相对安全 -
[data-*]：无索引，数量多时慎用，尤其避免[data-*^="prefix"] -
[style]：每次内联样式变更都会让整个选择器失效重算，高风险 - SVG 中的
[fill]、[d]：DOM 层面是普通属性，匹配成本高，建议用 class 控制状态
真要优化，优先改写法而非删属性选择器
与其砍掉所有 [data-]，不如把运行时逻辑前置：用 JS 在初始化时根据 data- 属性批量添加对应 class，后续样式全走 class 匹配。这样既保留语义化标记，又规避了重复属性扫描。
立即学习“前端免费学习笔记（深入）”；
// 初始化时一次性处理
document.querySelectorAll('[data-behavior="tooltip"]').forEach(el => {
el.classList.add('js-tooltip');
});
<p>/<em> 对应 CSS 就变成 </em>/
.js-tooltip { position: relative; }
.js-tooltip::after { /<em> ... </em>/ }属性选择器不是性能毒药，但它是“放大器”——本身不重，一旦混进低效结构或高频场景，问题就会被显著暴露。最常被忽略的其实是选择器右侧的锚定点是否足够稀疏，以及是否在无意中让浏览器去遍历整棵子树。
