.box .title 比 .final-box-title 慢得多，因为前者是后代选择器，需遍历DOM树逐级验证父级是否含.box类，属O(N)匹配；后者为单class哈希查找，接近O(1)，快一个数量级；伪类组合如.box:nth-last-child(-n+1) .title更达O(N²)开销。
为什么 .box .title 比 .final-box-title 慢得多
浏览器花在样式匹配上的时间，约一半用于遍历 DOM 树去验证选择器条件。像 .box .title 这种后代选择器，每次都要向上查父级是否含 box 类；而 .final-box-title 是单 class 匹配，直接哈希查找，快一个数量级。
更糟的是伪类组合，比如 .box:nth-last-child(-n+1) .title：浏览器得先收集所有子元素、排序、再定位倒数第 n 个，最后逐个检查其后代是否含 title。这不是“慢一点”，是 O(N²) 级别开销。
- 优先用唯一 class 名替代嵌套关系，哪怕多写几个字符（如
user-card-header而非.user-card .header） - 避免在高频更新区域（如列表项、表格行）使用属性选择器或
:not()、:has() - BEM 命名不是教条，关键是让每个样式规则只依赖一个 class，不隐含层级假设
哪些 DOM 变动会触发全量样式重计算
改一个 body 的 class，在旧浏览器里真会重算全部元素；现代引擎（Chrome/Blink、Firefox/Gecko）已优化为局部影响——但前提是：你没碰那些“全局开关”。
真正危险的操作包括：
立即学习“前端免费学习笔记（深入）”；
- 修改
document.documentElement或body的class/style属性（尤其含媒体查询相关类） - 动态插入/移除
<style></style>标签，尤其是带未加作用域的规则 - 用
innerHTML替换含大量节点的容器（会销毁重建整个子树，所有样式重新匹配）
安全做法是：给组件加 wrapper 并限定作用域，用 element.classList.toggle('active') 替代操作 body，用 DocumentFragment 批量插入而非反复 appendChild。
把任意文章或文档内容转换成精美的全屏翻页 HTML 演示文件（幻灯片风格）。当用户发来一篇文章、文档链接、Markdown 内容、或粘贴的文本，并且希望生成演示用的 HTML 时触发。支持任意内容来源：iWiki 链接、KM 链接、本地文件路径、直接粘贴的文本。生成的 HTML 文件保存到本地工作区，并通过企微直接发送给用户。触发词示例：帮我把这篇文章做成PPT、转成演示文档、生成HTML幻灯片、做个演示、转成可以演示的格式、article to deck、make a slide。
Chrome DevTools 里怎么定位样式计算瓶颈
打开 Rendering > Paint flashing 只能看到重绘，真正要抓样式计算，得进 Performance 面板录一段交互（比如滚动或点击），然后看 Layout 和 Recalculate Style 两项的耗时与调用栈。
关键线索：
- 如果
Recalculate Style时间长且调用次数多，说明选择器太复杂或匹配元素太多 - 若某次
Layout前紧跟着大块Recalculate Style，大概率是 JS 修改了 class 后触发了连锁反应 - 点开具体帧，看
Style calculation下展开的 “Rules matched” 数——超过 50 条/元素就是红灯
别只盯着 CSS 文件大小，getComputedStyle(element) 调用本身就会强制同步计算，循环里每调一次都可能拖慢一帧。
内联样式和 CSS-in-JS 真的更快吗
在大型本地 HTML 场景（如 20,000 行表格）中，内联 style 属性确实跳过了 CSSOM 构建和选择器匹配，实测加载快 60 倍——但这只对首次解析成立。后续 JS 动态改样式时，内联方式反而更慢：因为每次都要序列化 style 对象、拼字符串、设属性，而 class 切换只需一次 DOM 属性变更。
真正省时间的不是“不用 CSS”，而是“减少匹配工作”。所以：
- 静态内容用 class + 简洁选择器，别贪图“JS 控制一切”
- 高频动画用
transform/opacity，它们走合成层，绕过样式计算和布局 - CSS-in-JS 库（如 Emotion）默认生成唯一 class，本质还是 class 匹配，性能取决于它生成的选择器是否干净
最易被忽略的一点：即使你用了最简选择器，如果 DOM 节点数从 1000 涨到 10000，样式计算总耗时仍线性增长——优化选择器只能治标，删节点才是治本。
