动态插入DOM节点导致卡顿的主因是浏览器需重新计算CSS选择器匹配，尤其“从右到左”遍历的后代选择器（如.card-list div p span）在200个卡片渲染时会反复向上验证父级，引发CLS突增、掉帧和TTI延长。
为什么动态插入的 DOM 节点会让页面卡顿
不是因为 JS 执行慢，而是每次 innerHTML 或 appendChild 后，浏览器要重新计算所有 CSS 选择器匹配结果——尤其是那些“从右到左”遍历全量节点的选择器。比如你用 v-for 渲染 200 个卡片，而样式里写了 .card-list div p span，浏览器就得为每个 span 往上查父级，反复验证是否在 p、div、.card-list 里。
常见现象：CLS（累积布局偏移）突增、滚动掉帧、首次交互延迟（TTI）变长。
- 动态内容越多，后代选择器（空格分隔）性能衰减越明显
-
[data-testid]这类属性选择器在 dev 环境没问题，但上线后没剥离，就会在每次重排时触发全量 DOM 遍历 - 媒体查询里的选择器照样参与匹配，哪怕当前 viewport 不满足条件
怎么写 CSS 选择器才不会拖慢动态渲染
核心原则：让“关键选择器”（最右边那个）能快速定位目标元素，而不是靠层层往上验证。
- 用
.item替代.list li—— 类名查找是哈希 O(1)，后代选择器是线性扫描 - 避免
div#main，直接用#main；ID 本身唯一，加标签名反而多一次tagName判断 - 禁用
*和[data-xxx]在生产 CSS 中出现；如果必须保留测试属性，用 PostCSS 插件（如postcss-data-attr）构建时自动移除 - 深嵌套如
article > section > header > h1在 SPA 中插入新 article 时，会触发整条链路重匹配，换成.article-header更稳
HTML 结构怎么配合 CSS 做性能减负
语义化不只是 SEO 友好，更是减少选择器复杂度的物理基础。
立即学习“前端免费学习笔记（深入）”；
- 用
<nav></nav>替代<div class="nav">，然后直接写 <code>nav a—— 浏览器对原生标签的查找比 class 快一个数量级 - 避免无意义的包裹层：
<div><div><div><p>...</p></div></div></div>让.content p实际要扫三层无关 div - 动态生成的列表，给容器加明确类名（如
js-card-container），CSS 写成.js-card-container .card，不依赖 DOM 深度 - 慎用
display: contents：它会让父元素“消失”在可访问树和样式继承链中，某些选择器（如:has()）行为不可预期 - CSSOM 构建是阻塞的：哪怕一条
@media (min-width: 992px) { .hidden-on-mobile { display: none; } }在小屏下完全不生效，它仍参与首屏 CSS 解析 - 用
link rel="stylesheet" media="print"或外链独立文件隔离非关键样式，比内联 + 媒体查询更轻量 - 动态组件卸载时，别只删 DOM，检查是否遗留事件监听或未清理的
style标签 —— 多余的样式规则会持续参与匹配 - 构建工具里开
purgeCSS是基础，但要注意它可能误删动态 class（如bg-${color}），得配safelist
哪些优化手段容易被忽略但影响最大
没有报错、Lighthouse 也不标红，但真实用户感知明显。
