table布局、inline-block混用vertical-align、span与float混用会强制同步触发重排，因结构使浏览器无法预判尺寸；display: contents可减少重排扩散但存在兼容性与可访问性风险；contain: layout paint应加在内容更新明确的容器而非根节点。
哪些HTML结构会强制同步触发重排
浏览器不是“算得慢”，而是某些结构让它根本没法提前确定尺寸——一动就得全盘重算。最常踩坑的是：table布局，哪怕只改一个td的border或文字长度，整张表都可能重排；inline-block父容器里混用vertical-align，对齐依赖兄弟元素高度和行高，每次读写offsetHeight都会打断渲染队列；还有span + float混用，浮动脱离流后，后续元素定位必须反复回溯计算位置。
这些写法不报错、能显示，但只要你在 JS 里调一次getBoundingClientRect()，再顺手改个style.width，浏览器就只能当场 layout——不是你代码写错了，是结构没给它留缓存机会。
用display: contents替代无意义 wrapper 是否安全
display: contents能让父元素“消失”在渲染树中，子元素直接受其父级flex或grid容器控制，确实能减少一层布局上下文和继承链，降低重排扩散范围。但它不是万能胶：
- 不支持 IE，Safari 需 15.4+，Chrome 65+ 才稳定
- 会剥离可访问性树（
role、aria-*可能失效） - 若 wrapper 上绑了事件监听器或设置了
data-属性，这些逻辑仍存在 DOM 树中，但不再参与渲染——容易造成 JS 行为与视觉脱节
真正该删的是语义空壳，比如<div><div><p>文本</p></div></div>，而不是为了扁平化硬套display: contents去包裹一个带id或class的容器。
立即学习“前端免费学习笔记（深入）”；
contain: layout paint该加在哪个层级
contain是 HTML 层面最直接的“划界”手段，但加错位置反而拖慢性能。它适合加在内容频繁更新、且变化范围明确的容器上，比如聊天消息列表、商品卡片网格、实时图表区域。
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
不要加在根节点（如<body>）或全局布局容器（如.app-wrapper）上——这会切断样式继承、禁用部分getComputedStyle查询，甚至让子元素的position: fixed失效。
典型安全用法：
<ul id="message-list" style="contain: layout paint;"><div class="product-grid" style="contain: layout paint style;">
注意：contain: strict会更激进地隔离，但可能破坏z-index层叠上下文或伪元素渲染，上线前务必用 DevTools 的 Layers 面板验证图层划分是否符合预期。
初始 HTML 就该预留低开销操作空间
很多重排问题不在首屏，而在用户点击、滚动或搜索后。如果初始 HTML 没考虑后续 JS 操作路径，批量更新就会被迫高频触发重排。
需要动态增删列表项？初始就写<ul id="list"></ul>，别塞满 100 条再删；要切换 tab 内容？用<div class="tab-content"></div>占位，而不是靠 JS 插入完整 DOM 片段；轮播图容器高度要稳定？提前设min-height或用aspect-ratio锁定宽高比，避免图片加载后撑开引发重排。
真正难处理的不是你写的那几行 HTML，而是第三方 UI 库在mounted钩子或onShow回调里偷偷调用clientHeight又不做防抖——这时候得靠 Performance 面板录一段交互，看 Layout 事件是不是密集爆发，再针对性 patch。
