.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 名污染角度，它常更可靠。
XYCMS建站系统PHP版非MVC框架,自己手写原生态普通代码，作为企业用，已经绰绰有余。软件运行效率中等，加入数据缓存后性能提高。假如用来学习，下载可以慢慢研究的，假如用来建站，可以选择购买商业版就行建站用。栏目类别：文章，人员信息，专题项目，招聘，下载，相册，单页【支持无限极分类】文章：可用作添加新闻，资讯，列表信息类栏目信息人员信息：可用作企业员工信息栏目内容添加或者维护专题项目：可用作企业
立即学习“前端免费学习笔记（深入）”；
- 如果状态切换频繁（如 loading → success → error），用 class 切换需 JS 清理旧类，易遗漏；
dataset.state = 'success'自动覆盖 - 构建工具（如 PostCSS）可将
[data-*] 转为 class，兼顾语义与性能 - 真正在意性能的场景（如 Canvas 渲染层叠加 UI），应直接操作
className字符串或用toggleAttribute，避开选择器匹配环节
实际项目里，最常被忽略的是：选择器性能问题往往不出现在“写”的时候，而出现在“改”的时候——一个原本孤立的 .modal .content p，被后来人加到全局样式表里，又因嵌套组件增多，导致每次样式更新都要扫描整个 body 下所有 p。与其事后压测，不如把选择器长度和层级写进 CI 检查规则。
