HTML表格本身不慢，但动态渲染大量数据时因全表重排和自动列宽计算导致性能骤降；应强制table-layout:fixed、显式设列宽、批量innerHTML插入并补全无障碍属性。
HTML 表格本身不会显著拖慢数据渲染，但不当使用会引发严重性能问题——尤其是动态渲染大量行时，table 的重排（reflow）开销远高于 div 或 ul 布局。
为什么 table 渲染大量数据会变慢？
浏览器渲染 table 时需先解析全部 tr 和 td 才能确定列宽、对齐和跨行逻辑，无法像流式布局那样“边解析边画”。这意味着：即使只加 1 行，也可能触发整表重计算。
- 列宽自动计算（
table-layout: auto）是最大瓶颈，尤其当单元格含长文本、图片或内联样式时 -
colspan/rowspan会加剧布局复杂度，影响首屏绘制时间 - JavaScript 操作
tbody.appendChild()每次插入一行都可能触发同步重排
如何让 table 支持千行级数据快速渲染？
核心是切断“全量依赖”，用明确约束换性能：
- 强制设置
table-layout: fixed，并在col或第一行th中用width属性或 CSSwidth显式声明列宽 - 避免在
td内使用white-space: normal+ 长无空格字符串；改用word-break: break-word或截断 - 批量操作 DOM：把所有
tr拼成字符串后一次性写入innerHTML，而非循环appendChild - 启用虚拟滚动时，只渲染可视区域的
tr，并确保table容器有固定高度和overflow-y: auto
const rows = data.slice(start, end).map(row =>
`<tr><td>${row.id}</td><td>${row.name}</td></tr>`
).join('');
tbody.innerHTML = rows; // ✅ 比 100 次 appendChild 快 5–10 倍
table 和 div 布局在数据渲染场景怎么选？
不是“该不该用 table”，而是“语义是否匹配 + 是否可控”：
立即学习“前端免费学习笔记（深入）”；
- 纯展示型数据表格（如后台列表、报表导出）、需打印/屏幕阅读器支持、列对齐要求严格 → 用
table，但必须配table-layout: fixed - 高频增删、滚动加载、支持复杂交互（拖拽列、行内编辑、树形展开）→ 优先用
div+ ARIArole="table"，放弃原生table的语义便利性换控制力 - 服务端渲染（SSR）且数据量稳定 ≤ 200 行 →
table无压力，语义和 SEO 更优
容易被忽略的一点：table 的无障碍支持（如 scope、headers 属性）在动态渲染时极易丢失，每次重写 innerHTML 后必须手动补全这些属性，否则视障用户无法关联行列关系。
