大文本渲染慢主因是低效CSS选择器而非文本本身；后代选择器（如article p strong）从右向左匹配，导致浏览器对大量strong元素逐层回溯验证，200段落中可能耗时剧增。
为什么大文本渲染慢，往往不是文本本身的问题
真正拖慢渲染的，通常是作用于大量文本节点的低效选择器。比如 article p strong 这类后代选择器，在一篇含 200 段落、每段有多个 strong 的长文中，浏览器会先遍历全部 strong 元素（可能上千个），再逐层向上验证是否在 p 内、是否在 article 内——回溯开销远超文本排版本身。
关键选择器必须能直接定位到目标元素
浏览器匹配 CSS 是从右往左的，最右边那个部分叫“关键选择器”，它决定了初始候选集大小。对大文本场景，关键选择器必须足够唯一、可被哈希索引：
- ✅ 推荐：
.text-highlight、[data-role="emphasis"]、span.highlight（前提是span数量可控） - ❌ 避免：
p em（em太泛）、section > *:nth-of-type(odd)（伪类强制全量计算）、body .content *:not(.ignore)（*+:not()组合是性能黑洞） - ⚠️ 特别注意：加了 class 不等于安全——
.article-body div p code问题仍在最右的code，如果页面有 500+code标签，仍会触发大规模回溯
用 DevTools 快速验证选择器实际开销
Chrome 115+ 可启用实验性 CSS 选择器分析（需访问 chrome://flags/#devtools-css-selector-profiling 开启），然后在 Elements 面板 Styles 侧边栏悬停规则，就能看到实时估算的「匹配节点数」和「耗时等级」。没开启时，也能手动验证：
- 在控制台运行
document.querySelectorAll("your-selector")，结果超过 300 就该警惕 - 录制 Performance 面板操作，筛选
Recalculate Style事件，点开 → Related Events → 找到触发它的 CSS 规则行号 - 若某条规则在滚动或动态插入文本后频繁触发 Layout/Style 计算，基本可判定为瓶颈源
大文本场景下容易被忽略的隐性陷阱
很多人优化完选择器就以为结束了，但以下两点常被跳过，却直接影响长文滚动与动态加载的流畅度：
立即学习“前端免费学习笔记（深入）”；
- 全局通配规则如
body * { line-height: 1.6; }，每次插入新段落、甚至切换暗色模式时，都会重匹配整个body子树——对万字文档就是灾难 - 使用
:has()或:is()等现代伪类时，若内部含复杂子选择器（如p:has(span.highlight strong)），匹配成本呈指数上升，目前无有效缓存机制 - 框架中动态添加 class（如 React 的
className={isActive ? "active" : ""}）若配合低效选择器，会导致样式计算反复触发，比静态 HTML 更敏感
