原生能撑起复杂排版，但易因rowspan/colspan位置错误、语义结构混乱（如未置于前）、顺序错位及缺乏草图规划导致跨行跨列错位、维护困难；超200行时应借助datatables或虚拟滚动优化性能。
原生 <table> 完全能撑起复杂排版，但关键不在“能不能”，而在“怎么写不出错”——跨行跨列错位、语义混乱、后续维护改一行崩三行，是高频翻车点。
<h3>rowspan 和 colspan 必须从最顶行/最左列开始写</h3>
<p>典型错误是把 <code>rowspan="3" 写在第 2 行的 <td> 上。它不会向上覆盖已渲染的单元格，只从当前行向下占位。如果想让某个表头纵向贯穿前三行，<code>rowspan="3" 必须出现在第 1 行对应列的 <th> 或 <code><td> 上，且该位置原本不能有其他单元格。
<ul><li>跨列同理：<code>colspan="2" 必须放在它要覆盖的最左列单元格上，左侧不能有未闭合的 <td>
<li>合并后，被覆盖区域的其他 <code><td>/<code><th> 必须删掉，否则会多出单元格导致错列
<li>建议先画草图，标出每格行列坐标（从 0 开始），再填 <code>rowspan/colspan 值，比边写边试快得多
thead/tbody/tfoot 不只是语义标签，还影响渲染顺序和样式隔离
<thead> 和 <code><tfoot> 必须是 <code><table> 的直接子元素，且 <code><tfoot> 要写在 <code><tbody> 之前——浏览器会自动把它渲染到底部，但 DOM 顺序必须如此，否则 JS 操作或打印样式可能异常。
<ul><li><code><tbody> 是唯一可重复出现的分组标签，适合用 JS 动态插入多段数据
<li>给 <code><thead> th 单独加 <code>position: sticky; top: 0; 实现固定表头时，<tbody> 必须有明确高度（如 <code>max-height: 400px; overflow-y: auto;），否则 sticky 失效
tbody tr:nth-child(even) 做斑马纹时，样式只作用于 <tbody> 内的行，<code><thead> 不受影响
<h3>colgroup/col 是控制列样式的唯一干净方式</h3>
<p>给每列单独设宽度、背景色或对齐方式，别在每个 <code><td> 上重复写 <code>style。用 <colgroup></colgroup> + <col> 可以统一管理，且不影响语义结构。
-
<colgroup></colgroup>必须紧贴<table> 开始标签之后，不能放在 <code><thead> 里 <li> <code><col>标签本身不闭合，也不需要内容，靠span属性可批量控制多列，例如<col span="2">同时影响前两列 - 设置列宽优先级：CSS
width><col>的width><td> 的 <code>width，但列宽受表格总宽和内容挤压影响，实际效果需测试超过 200 行或需要交互功能时，别硬扛原生 table
DOM 节点一多，
<table> 渲染和重排压力直线上升，滚动卡顿、排序响应慢、甚至触发浏览器强制重绘。这不是代码问题，是原生机制限制。 <ul><li>纯静态页面：引入 <code>datatables.net，它底层仍是<table>，但做了虚拟滚动、懒加载和事件委托 <li>React/Vue 项目：保留 <code><table> 语义结构，但用 <code>react-virtualized或vxe-table包裹，避免全量渲染 - 完全动态场景（如实时日志流）：考虑用
display: grid+grid-template-rows: repeat(100, auto)配合滚动监听，性能更可控
复杂表格真正难的不是写出来，而是改的时候知道哪一行删了会影响哪几列的 rowspan 计算，以及 <colgroup></colgroup> 的顺序一旦错，整列样式就乱套——这些细节不画图、不验证，光靠浏览器刷新很难发现。
