Colgroup对渲染性能几乎没有提升，现代浏览器中它不影响FPS、首屏时间或重排开销；其真实价值在于结构可维护性，如通过span属性配合JS稳定映射动态列组，而非加速渲染。
Colgroup 对渲染性能几乎没有提升
别指望 <colgroup> 能“加速表格渲染”——现代浏览器里，它对 FPS、首屏时间、重排开销基本没影响。所谓“提前声明列宽可优化布局”的说法，是十年前旧引擎的遗留认知。当前 Chromium、WebKit 和 Gecko 都在解析 <tr> 时才真正计算列宽，<col> 的 width 只是初始建议值，不参与 layout 阶段的早期优化。
真正影响性能的是 table-layout: fixed + width 显式设置
如果你确实观察到滚动更顺滑或首次绘制更快，那功劳不在 <colgroup> 本身，而在它配合 table-layout: fixed 和具体 width 值带来的确定性：
-
table-layout: fixed关闭了浏览器逐行扫描内容以推导列宽的逻辑，避免反复 reflow - 每列
<col>都设了明确width（如120px或20%），浏览器跳过 content-based sizing 计算 - 没设
width的列在fixed模式下会坍缩为 0（尤其 Safari），导致整列不可见——这不是 bug，是规范行为
海量数据下，colgroup 的唯一实际价值是结构可维护性
当表格有 20+ 列、分组动态切换（比如“用户基础信息”“行为埋点”“付费转化”三组），靠 th:nth-child(1) 到 th:nth-child(7) 这种硬编码 selector 极易出错。而用 <col span="7" id="user-base"> 配合 JS 读取 document.querySelector('#user-base').span，能稳定映射列范围。但这和性能无关，只降低维护成本。
容易被忽略的陷阱：span 总和≠列数 → 样式静默漂移
这是最隐蔽的性能“假象”：表格实际有 12 列，但 <colgroup> 里写了 <col span="5"><col span="6">（总和 11），最后一列失去所有 <col> 控制。浏览器不会报错，但该列回退到 auto-width + 无背景色，后续所有依赖列序的 JS 逻辑（如列冻结、导出选中列）都可能错位——问题表现在交互层，排查时却常误判为“渲染卡顿”。
立即学习“前端免费学习笔记（深入）”；
