CSS选择器匹配从右往左，.header .nav .item:hover需回溯验证父级，而.nav-item:hover直接哈希查找；BEM通过命名契约替代结构依赖；@import阻塞并串行加载，应禁用；重排由布局相关API或伪类触发，非选择器长度本身。
为什么 .header .nav .item:hover 比 .nav-item:hover 更慢
浏览器匹配 CSS 选择器是从右往左的，.header .nav .item:hover 要先找所有 :hover 元素，再往上逐层验证父级是否匹配。DOM 越大，回溯开销越明显。而 .nav-item:hover 是单类名，直接哈希查找，几乎无额外成本。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 避免连续多个后代选择器（
div ul li a），尤其在高频交互区域（如菜单、卡片列表） - 用语义化类名替代结构路径，比如把
article > section > h2改成.article-title - 慎用通配符和属性选择器：
[class*="btn"]或* + p会强制全量扫描
如何安全地用 BEM 替代嵌套写法
BEM（Block__Element--Modifier）不是语法糖，是把“结构依赖”转为“命名契约”。它不靠 DOM 层级，靠类名本身表达关系，所以不会因模板微调就失效。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 块名必须唯一且具业务含义：
.search-form✅，.form❌（太泛，易冲突） - 元素名不带父级前缀：
.search-form__input✅，.search-form__form-input❌（冗余） - 修饰符只用于状态或变体：
.button--disabled✅，.button--large-red-shadow❌（耦合样式，难维护）
@import 和 <link> 引入 CSS 的性能差异
@import 是 CSS 规则，解析时会阻塞后续规则，并且无法并行下载——浏览器发现 @import 后，必须先获取并解析完那个文件，才能继续处理当前文件里剩下的内容。而 <link rel="stylesheet"> 是 HTML 解析阶段就发起的并行请求。
常见错误现象：页面首屏白屏时间变长，DevTools Network 面板里出现串行加载瀑布流。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 彻底禁用
@import，哪怕只在本地开发中用也不推荐 - 拆分 CSS 时，用构建工具（如 PostCSS、Webpack）做合并，而不是靠
@import组织源码 - 关键样式（如字体、首屏布局）内联到
<style>，非关键用<link rel="preload" as="style">提前拉取
哪些 CSS 选择器会触发重排（reflow）或强制同步布局
真正影响性能的不是选择器本身多长，而是它是否导致浏览器必须读取布局信息来计算样式。例如 :nth-child(n)、:first-letter 或任何依赖兄弟/父子关系的伪类，在 DOM 变动后可能引发重排。
更隐蔽的是 JavaScript 中读取 offsetTop、getComputedStyle() 等 API 后，又立即改写样式——这会强制同步计算，打断渲染流水线。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 避免在循环中读写交替：
el.offsetTop→el.style.left = ...→el.offsetTop - 用
transform和opacity做动画，它们走合成层，不触发布局计算 - 复杂交互组件（如下拉菜单、折叠面板）用
will-change: transform提前提示，但别滥用
事情说清了就结束。最常被忽略的其实是「选择器性能」和「布局触发」根本不是一回事——前者影响样式计算速度，后者直接卡帧。改选择器只是起点，后面得盯住 DevTools 的 Rendering 面板看 layout forced。
