.container .item 比 .container-item 慢，因前者需从右向左匹配所有 .item 并逐个回溯祖先是否含 .container，而后者为单类名哈希查找、无回溯；BEM 等扁平命名本质是绕过层级匹配而非仅规范命名。
为什么 .container .item 比 .container-item 慢
CSS 选择器是从右向左匹配的，浏览器先找所有 .item 元素，再向上检查其祖先是否含 .container。这意味着哪怕 DOM 很深、.item 很多，它都得逐个回溯。而 .container-item 是单类名，直接哈希查找，无回溯开销。
- 层级越深（如
div ul li a:hover），右侧基础匹配集越大，性能越差 - 通用选择器（
*）、属性选择器（[type="text"]）、伪类（:nth-child()）都会阻止优化，强制遍历 - 用 BEM 命名（如
.header__logo--large）本质是用语义换选择器扁平化，不是“为了命名规范”，而是绕过层级匹配
:is() 和 :where() 能否真正提升性能
它们本身不提速，但能减少重复规则，间接降低 CSS 文件体积和解析压力；更重要的是，:where() 的权重要忽略，可安全组合高权重选择器而不破坏样式优先级。
.btn:where(:hover, :focus) { color: blue; }
/* 等价于写三个独立规则，但 specificity = 0 */
/* 避免了 .btn:hover { color: blue; } + .btn:focus { color: blue; } 的冗余 */
-
:is()取组内最高 specificity，可能意外覆盖其他规则 -
:where()总是 0，适合复用逻辑但不想干扰权重的场景 - 二者都不改变底层匹配路径，别指望靠它们“优化慢选择器”——该拆还是得拆
哪些选择器会触发全局重排或强制同步布局
没有选择器本身会触发重排，但若选择器用于 getComputedStyle() 或 offsetTop 等读取布局 API，且匹配结果依赖未完成的样式计算（比如刚插入未渲染的节点），就可能触发强制同步布局（forced synchronous layout）。
- 避免在循环中用
document.querySelectorAll('.list-item')后立刻读el.offsetTop - 用
element.classList.contains('active')替代matches('.active')，前者不触发样式计算 - 动态插入元素后，如需批量读取布局，用
requestAnimationFrame延迟到下一帧，让浏览器先完成样式/布局计算
用 data- 属性替代 class 做状态选择是否划算
单纯从匹配速度看，[data-state="loading"] 比 .is-loading 略慢，因为属性选择器无法被 CSS 引擎索引优化；但从维护性和避免 class 名污染角度，它常更可靠。
