必须显式使用包裹动态行，避免浏览器自动补全不一致；推荐克隆填充+DocumentFragment批量插入；设table-layout:fixed并明确列宽；大数据量用虚拟滚动。
表格结构必须用 <tbody> 包裹动态数据行
<p>直接往 <code><table> 里拼接 <code><tr><td>... 字符串，容易漏掉语义结构，导致后续用 JS 操作（比如排序、高亮某行）时找不到父容器。浏览器对缺失 <code><tbody> 的表格会自动补全，但补全行为不一致——Chrome 和 Firefox 可能插入位置不同，造成 <code>document.querySelector('tbody').children.length 在某些情况下返回 0。
实操建议：
- 所有含动态数据的表格，显式写出
<tbody> 标签，哪怕初始为空 <li>JS 渲染时只操作 <code><tbody>，用 <code>innerHTML或append()插入<tr>，别碰 <code><thead><li>避免用 <code>document.write()或直接改<table>.innerHTML，会重置整个表格状态（比如已展开的详情行、输入框焦点） <h3> <code>template标签 +content.cloneNode(true)是最稳的渲染方式用字符串模板拼接 HTML 容易出 XSS，用
innerHTML再解析又慢；而document.createElement逐个建节点太啰嗦。折中方案是把单行结构预定义在<template></template>里，运行时克隆、填值、插入。示例（假设每行有 name、age、status）：
立即学习“前端免费学习笔记（深入）”；
<template id="row-template"> <tr> <td class="name"></td> <td class="age"></td> <td class="status"></td> </tr> </template>JS 端操作：
- 用
document.getElementById('row-template').content.cloneNode(true)获取干净副本 - 用
row.querySelector('.name').textContent = item.name填值，比正则替换或 innerHTML 更安全 - 批量插入前先用
DocumentFragment收集所有<tr>，再一次性 append 到 <code><tbody>，避免反复重排 <h3>表格列宽错乱？检查 <code>table-layout: fixed和width设置数据渲染后列宽忽宽忽窄，常见原因是浏览器按内容自动计算列宽，新插入的长文本把整列撑开，影响其他行对齐。尤其在分页加载、搜索过滤后重新渲染时更明显。
- 给
<table> 加 CSS：<code>table-layout: fixed，强制按第一行（或<col>）宽度分配空间 - 在
<colgroup></colgroup>或<thead> 的 <code><th> 上设明确 <code>width（如width: 120px或width: 20%），别依赖min-width - 如果某列内容需换行，加
word-break: break-word到<td>，别用 <code>white-space: normal—— 后者在固定布局下可能失效大数据量渲染卡顿？优先用虚拟滚动，别硬塞几万行
渲染超过 2000 行就明显卡，不是 JS 慢，是浏览器要为每个
<tr> 创建 layout tree 节点。哪怕数据只是纯文本，DOM 节点数一多，scroll、resize 都会掉帧。 <ul><li>真实场景下，用户一次只看视口内 20–50 行，其余行用空白 <code><tr> 占位（高度由 <code>style.height控制），靠scrollTop动态更新中间区域的内容 - 不要自己手写虚拟滚动逻辑，用成熟库如
react-window（React）或vue-virtual-scroller（Vue），它们已处理好滚动条同步、键盘导航、IE 兼容等细节 - 如果非得原生实现，注意监听
scroll时用requestIdleCallback节流，且只更新<tbody> 中可见范围内的 <code><tr>，别动整个 <code><tbody>.innerHTML <p>表格和数据渲染真正难的不是“怎么显示”，而是“怎么不让它崩”——DOM 节点生命周期、样式继承链、滚动事件触发时机，这些地方稍不留意，就会在某个 Chrome 版本或某种缩放比例下突然失灵。</p> </tbody>
- 给
- 用
