多重嵌套<table>会触发浏览器强制“拍平”DOM：外层<table>被截断，内层被提升为兄弟节点甚至移至<body>下，导致节点数失控、样式继承断裂、选择器失配。
多重嵌套 <table> 会直接触发浏览器自动修复 DOM
浏览器解析器遇到 <table><table><tr><td>...</td></tr></table></table> 这类结构时，不会按你写的层级构建 DOM，而是依据 HTML 规范强制“拍平”：外层 <table> 被截断，内层 <table> 被提升为兄弟节点，甚至可能被移到 <body> 下。这不是 bug，是规范要求的容错行为。
后果很实在：<table> 嵌套超过 1 层，DOM 节点数就不可控增长，样式继承链断裂，querySelector('table tr td') 可能匹配不到预期元素——因为真实 DOM 已不是你写的结构。
- 用 Chrome DevTools → Elements 面板右键任意
<table>→Show DOM properties，检查parentNode和实际位置是否符合预期 - 在控制台运行
document.querySelectorAll('table').length，对比你写的<table>标签数量，差值就是被“修复”出来的额外节点 - 特别注意 CMS 或富文本编辑器导出的 HTML，常含
<table><tbody><tr><td><table>...这类看似合法实则违规的嵌套
<td> 里再套 <div> 是性能雷区
<td> 的内容模型只允许 phrasing content（如 <span>、<em>、文本），<div> 属于 flow content，禁止直接子元素。浏览器实际解析结果是：<td><div>xxx</div></td> → 拆成 <td></td><div>xxx</div><td></td>。
这导致三件事同时发生：空 <td> 节点增加、表格布局上下文重建、行高计算异常。在 50 行以上表格中，这种写法会让 layout 阶段耗时翻倍。
立即学习“前端免费学习笔记（深入）”；
- 真需要块级容器？改用
<span style="display:block">或语义更准的<small>/<aside> - React/Vue 中 JSX 写
<td><div>...</div></td>同样触发该行为，编译不报错，但运行时 DOM 已变形 - 用
getComputedStyle(document.querySelector('td')).height测量，若返回auto或异常值，大概率是被拆解导致的布局断裂
测试多重 <table> 渲染衰减的可靠方法
别测“页面加载时间”，那混杂了网络、JS 执行、CSS 解析；要测纯解析 + 构建阶段开销，得绕过干扰项。
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
最简验证方式：取一段纯 HTML 字符串（不含 JS/CSS），用 performance.mark() + performance.measure() 锁定 DOM 构建耗时：
const html = `<table><tr><td>1</td></tr></table>`.repeat(100); // 生成 100 个 table
performance.mark('start');
const div = document.createElement('div');
div.innerHTML = html; // 触发解析和 DOM 构建
performance.mark('end');
performance.measure('table-parse', 'start', 'end');
对比嵌套版：<table><tr><td><table>...</table></td></tr></table>，相同节点数下，后者 DOM 构建耗时通常高出 3–5 倍。
- 用
chrome://tracing录制，筛选ParseHTML和Layout阶段，看耗时分布是否集中在 Tree Construction - 禁用所有样式（
document.styleSheets[0].disabled = true）再测，排除 CSS 计算干扰，专注验证解析器行为 - 移动端务必在真机上测——iOS WebKit 对
<table>嵌套的修复逻辑比 Chromium 更激进，有时会多生成 2–3 倍节点
替代方案不是“怎么嵌套更好”，而是“根本不用嵌套”
<table> 本就不该用于布局，多重嵌套更是反模式。现代渲染瓶颈不在“能不能画出来”，而在“浏览器花了多少时间搞清楚你要画什么”。
表格数据展示场景下，真正有效的降级路径是：
- 纯展示表格：用
<table>，但确保单层、无<div>套<td>、<thead>/<tbody>结构完整 - 复杂布局需求（比如表头吸顶+横向滚动+可展开行）：放弃
<table>，用display: grid或display: table-cell模拟，DOM 深度压到 2–3 层 - 超大数据量（万行以上）：不用任何 HTML 表格标签，用
document.createDocumentFragment()+requestIdleCallback分帧追加<div role="row">元素
关键点在于：浏览器解析器对 <table> 的处理是硬编码逻辑，无法靠 CSS 或 JS 绕过。想快，就得让它少干活——而不是教它怎么更优雅地干脏活。
