是浏览器分块渲染表格的底层开关，加了它数据行能“边下边出”，提升慢网和SSR首屏速度；必须显式用多个包裹数据行（每段50–100行为宜），且须与、共存并严格按此顺序书写，否则结构不合法、渲染异常或无障碍失效。
<tbody> 不是可选装饰，它是浏览器分块渲染表格的底层开关。没它，大表格得等全部 HTML 下载完才显示；加了它，数据行能“边下边出”，尤其对慢网或 SSR 场景很关键。
<h3>为什么<tbody>能加快长表格首屏显示
<p>浏览器解析 <code><table> 时，默认按整块处理：必须收齐所有 <code><tr> 才开始渲染。而一旦出现 <code><tbody>，浏览器就把它当作一个独立渲染单元，只要该 <code><tbody> 内容下载完成，立刻绘制，不卡后面的 <code><tbody> 或其他 DOM。
<p>常见错误现象：<code>页面白屏几秒后，整个大表格突然弹出来 —— 很可能就是没包 <tbody>，或者只在最外层套了一个，但数据量太大仍不够分段。
<ul><li>必须把数据行用 <code><tbody> 显式包裹，不能依赖浏览器自动补全（虽然部分浏览器会补，但不保证渲染时机）
<li>单个 <code><tbody> 包含 50–100 行较稳妥；超过 200 行建议拆成多个 <code><tbody><li>不要在 <code><tbody> 外直接写 <code><tr>，否则语义断裂，部分旧版 Safari 可能忽略渲染优先级
<h3>多个<tbody>如何配合 JS 动态控制显隐
<p>用多个 <code><tbody> 替代反复操作大量 <code><tr>，DOM 更新更轻量，也避免重排扩散。
<p>使用场景：折叠/展开分类数据、按条件切换数据视图（如“仅显示错误订单”）、分页加载时替换区块。</p>
<ul><li>每个 <code><tbody> 加唯一 <code>id 或 data-section，方便 document.querySelector 精准定位
style="display: none"，不要用 remove()——保留结构利于后续 show/hide 切换<tbody>：<code><tbody></tbody>
<tbody>...</tbody>
是非法 HTML，Chrome 会自动截断，Firefox 可能报错与
共存时的顺序和兼容性陷阱
<thead>、<code><tfoot>、<code><tbody> 的书写顺序必须是 <code><thead> → <code><tfoot> → <code><tbody>，哪怕逻辑上 <code><tbody> 数据最先生成。这是 W3C 强制要求，否则：
<ul><li>某些 IE 版本或 Electron 内核会乱序渲染（<code><tfoot> 跑到中间）
<li>屏幕阅读器可能跳过 <code><tbody> 内容，影响无障碍访问
<li>打印时页脚无法跨页重复（<code><tfoot> 必须在 <code><tbody> 前声明才能被识别为“每页脚注”）
<p>注意：<code><thead> 和 <code><tfoot> 不是可选的——只要用了其中任意一个，就必须三者齐全，否则结构不合法。
<p>真正容易被忽略的是：即使你只想要分段加载，也得老老实实写全 <code><thead> 和 <code><tfoot>（哪怕 <code><tfoot> 为空），否则浏览器可能降级回整表阻塞渲染。这不是过度设计，是规范落地的硬门槛。</tfoot>
<thead>、<code><tfoot>、<code><tbody> 的书写顺序必须是 <code><thead> → <code><tfoot> → <code><tbody>，哪怕逻辑上 <code><tbody> 数据最先生成。这是 W3C 强制要求，否则：
<ul><li>某些 IE 版本或 Electron 内核会乱序渲染（<code><tfoot> 跑到中间）
<li>屏幕阅读器可能跳过 <code><tbody> 内容，影响无障碍访问
<li>打印时页脚无法跨页重复（<code><tfoot> 必须在 <code><tbody> 前声明才能被识别为“每页脚注”）
<p>注意：<code><thead> 和 <code><tfoot> 不是可选的——只要用了其中任意一个，就必须三者齐全，否则结构不合法。
<p>真正容易被忽略的是：即使你只想要分段加载，也得老老实实写全 <code><thead> 和 <code><tfoot>（哪怕 <code><tfoot> 为空），否则浏览器可能降级回整表阻塞渲染。这不是过度设计，是规范落地的硬门槛。</tfoot>
