document.body连续appendchild触发100次重排，是因为每次调用都变更dom树，浏览器必须立即验证布局有效性；body作为顶层元素，子节点增删会引发全局流式计算，含内联或浮动子项时重排更会向上扩散至html或document级别。

为什么 document.body 里连续 appendChild 会触发 100 次重排

不是浏览器“反应过度”，而是每次 appendChild() 都让 DOM 树发生变更，浏览器必须立刻验证布局有效性——尤其当父容器是 body 这种顶层元素时，任何子节点增删都可能影响全局流式计算（比如行高继承、块级上下文重置）。更糟的是，如果这些新节点含内联元素或浮动子项，重排还会向上扩散到 html 或 document 级别。

• 每调用一次 appendChild()，浏览器就执行一次样式计算 + 布局 + 绘制流水线，哪怕只加一个空 div
• 若节点含文本，字体加载、行盒生成、换行判定都会被重新触发
• 避免方式：用 document.createDocumentFragment() 收集全部节点，最后只调用一次 appendChild()

display: inline-block 容器里 vertical-align 怎么偷偷放大重排范围

表面看只是对齐控制，实际它让浏览器无法跳过几何计算——vertical-align 的值（baseline、middle 等）依赖当前行内盒的高度、父容器行高、兄弟元素字体大小，三者任意变化都会迫使整行重排。更隐蔽的是，这种重排会向上传播：父容器若为 flex 或 grid，其子项尺寸变动会触发容器自身重排。

• 常见错误：在 div 上设 display: inline-block，再给子 span 加 vertical-align: top，结果滚动时整个导航栏卡顿
• 替代方案：改用 flex 布局 + align-items，或直接用 transform: translateY() 微调位置
• 注意：vertical-align 在表格单元格中同样危险，且无法被 contain: layout 截断

table 布局为何一改 td 就全表重排

表格布局没有局部优化机制。浏览器必须为每个 td 计算列宽，而列宽又取决于该列所有单元格内容长度、white-space、min-width 等，且受同行其他单元格约束。改一个 td 文本，就可能让整列宽度重算，进而影响所有行的换行和高度，最终触发整表重排。

html-to-pptx-converter

使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。

下载

• 即使设置了 table-layout: fixed，只要没给 col 或 th 显式设宽，浏览器仍会回退到自动算法
• 动态插入 tr 或删除 td 是最差场景，几乎必然全表重排
• 可行替代：用 display: grid 模拟表格结构，列宽可独立控制，增删项仅影响局部渲染树

非法嵌套如

为何让重排从局部变全局

浏览器解析时发现 <p></p> <div>...</div>

违反规范，会立即中断 p 标签，把 div 提到外面，再补一个闭合 和新开 <p></p>。这个 DOM 自动修正过程不是“静默修复”，而是触发三次独立样式计算：原 p、新 div、后续补出的 p。更严重的是，若原 p 在 body 直接子级，修正后 div 可能变成 body 新子节点，导致 body 重排。

• 检查方法：DevTools Elements 面板里看 ol 或 ul 的直系子节点是否全是 li；如果不是，说明有非法内容被剥离
• 语义标签如 <main></main>、<section></section> 能减少这类风险——它们默认无 margin/padding，且浏览器对其解析更宽容
• 真正关键点：重排扩散不是因为代码“写得丑”，而是浏览器在修正过程中不得不重建部分渲染树

前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！