属性选择器匹配发生在样式计算阶段，浏览器在构建DOM节点时即调用cssMatcher.match(node)进行匹配，[type="submit"]等选择器在<input>节点创建后立刻参与匹配，不等待样式表解析或JS执行完成。
属性选择器匹配发生在样式计算阶段，不是渲染时才执行
浏览器在构建 DOM 节点的同时，就对每个节点调用 cssMatcher.match(node)，[type="submit"] 这类选择器会在 <input> 节点创建后立刻参与匹配。它不等 document.styleSheets 解析完成，也不等 JS 执行完——这意味着你写下的 [data-id]，从第一个带该属性的元素被解析起，就已经进入匹配流水线。
常见错误是以为“动态加 data-* 就能触发样式生效”，其实不会：CSS 引擎不监听属性变更，el.setAttribute('data-loaded', 'true') 后，已存在的规则不会重算；只有新增节点才会走一遍匹配流程。
[attr] 和 [attr="val"] 的开销差异其实很小，但语义完全不同
[attr] 只查属性是否存在，引擎直接读 DOM 节点的 attributesMap，接近 O(1)；[attr="val"] 需取值再做字符串全等比较，多一次内存读取和比对。现代浏览器里这两者耗时差距通常不到 0.01ms，真正拖慢的是选择器组合方式。
-
[class]会命中<div class="">和<div class=" ">，而.my-class天然跳过空值 -
[lang="en"]不匹配lang="EN"，即使 HTML 规范说不区分大小写——CSS 匹配纯按字面 -
[data-id="123 abc"]必须加引号，否则解析器截断为data-id="123"，空格后内容丢失
深层嵌套 + 属性选择器（如 .card [data-type="title"]）是性能双杀
浏览器从右往左匹配：[data-type="title"] 先全量扫描所有带该属性的元素，再逐层向上验证是否在 .card 内。两重低效叠加：属性扫描 + 多层回溯。实测在低端 Android 设备上，比 .card__title 慢 4 倍以上。
立即学习“前端免费学习笔记（深入）”；
容易被忽略的场景包括：
- CSS-in-JS 库（如 Emotion）自动生成的
[data-styled]类选择器 - 构建工具注入的测试属性，比如未剥离的
[data-testid] - 媒体查询里的后代选择器，如
@media (max-width: 768px) { .sidebar ul li a { } }—— 这条规则在所有尺寸下都参与匹配
~=、^=、$=、*= 不是正则，只是朴素字符串操作
它们不支持转义、不支持通配符，[href*="http://"] 不能写成 [href*="http:\/\/"]，反斜杠会被当作普通字符处理；[class^="btn-"] 只看属性值开头，不关心单词边界，所以匹配 class="btn-primary"，但不匹配 class="primary btn"。
最常误用的是 [data-tags~="react"]：它要求 data-tags 值必须是空格分隔的单词列表（如 data-tags="react vue svelte"），而不是任意包含 react 的字符串。
真正影响性能的从来不是单个属性选择器，而是它出现在高频更新区域（比如每帧重绘的动画列表）或与其他低效模式叠加——这时候，[data-*="xxx"] 无法被 CSS 引擎缓存优化，不像 ID 或 class 有哈希索引。
