浏览器解析嵌套时实际生成并列兄弟关系而非父子嵌套，因解析器会自动闭合外层再新建独立表格上下文，导致子表格脱离原单元格成为文档级节点。
浏览器解析嵌套 <table> 时根本不会“嵌套”
<p>嵌套 <code><table> 在 DOM 中实际是**并列兄弟关系**，不是父子嵌套。因为 <code><td> 的内容模型只允许 <em>flow content</em>，而 <code><table> 属于 flow content，所以语法上合法；但关键在于：浏览器在解析到 <code><td> 内的 <code><table> 开始标签时，会**自动闭合当前 <code><td> 和其外层 <code><tr>、<code><table>**（如果尚未闭合），再新建一个独立表格上下文。
<p>常见错误写法：</p>
@@######@@
<p>实际生成的 DOM 结构近似为：</p>
@@######@@
<p>也就是说：外层 <code><td> 被提前截断，内层 <code><table> 成为文档级节点，与外层表格平级。
<h3><code><tbody> 自动补全如何影响嵌套表格的内存布局
<p>每个独立 <code><table> 都会被解析器强制插入 <code><tbody>（即使源码没写）。这意味着：哪怕你只写 <code><table><tr><td>x</td></tr></table>，最终 DOM 中会有 <table><tbody><tr><td>x</td></tr></tbody></table>。嵌套场景下，每个子表格都自带完整结构树，包括自己的 <tbody>、<code><tr>、<code><td> 节点对象。
<p>这直接导致：</p>
<ul>
<li>内存中存在多个独立的 <code>HTMLTableElement 实例，各自维护 rows、caption、tBodies 等属性引用
<tbody> 是独立的 <code>HTMLTableSectionElement，不共享父表格的 tBodies 列表
document.querySelectorAll('table tbody')，结果包含所有嵌套层级的 <tbody>，无法靠选择器天然区分归属
<h3>用 <code>innerHTML 拼接嵌套表格时的结构撕裂风险
实时拼接嵌套表格最危险的操作是分多次赋值 innerHTML，例如：
|
第二次赋值时，浏览器把新字符串当作**全新 HTML 片段**解析，完全无视前一次状态。结果是：
- 第一次写入触发自动闭合：生成
<table><tbody><tr><td>A</td></tr></tbody></table> - 第二次写入被当独立片段：
<td>B</td>
<td>（无 <code><tr> 包裹）、无效闭合标签
<li>最终 DOM 出现错位、丢失样式、JS 查询失败</li>
<p>正确做法只有两种：</p>
<ul>
<li>拼好完整字符串再一次性写入 <code>innerHTML
insertAdjacentHTML('beforeend', ...) 或 DocumentFragment 手动构造节点为什么调试工具里看到的 DOM 树和你写的 HTML 对不上
开发者工具显示的是**已修正的 DOM 树**，不是原始 HTML 字符串。嵌套表格的“视觉嵌套”只是渲染层的错觉——实际节点路径中，子表格根节点的 parentNode 很可能指向 或某个 <div>，而不是你预期的 <code><td>。这点在以下场景尤为致命：
<ul>
<li>CSS 作用域：写 <code>td table { border: 1px solid red; } 可能不生效，因为 table 已不在 td 内部
td 上的 click，子表格内点击不会冒泡过来真正决定行为的是修正后的节点关系，不是源码缩进或视觉位置。检查时务必看 node.parentNode 和 node.parentElement，而不是依赖 Elements 面板的折叠样式。
| inner |
cell.innerHTML = '
| A | '; // 不完整 setTimeout(() => { cell.innerHTML += 'B |
