IE11中table-layout: fixed列宽不生效，因其仅识别<col>标签的显式像素宽度（如width="120"），无视百分比、min-width及单元格样式；必须用<colgroup>包裹且每个<col>设px值，DOM中需置于thead前。
table-layout: fixed 为什么在 IE11 里列宽完全不生效
IE11 对 table-layout: fixed 的支持极度依赖 <col> 标签的显式像素宽度，且会无视 min-width、width 百分比、甚至内联 style="width: 30%"。它只认 <col width="120"> 或 <col style="width: 120px"> 这类带明确 px 值的定义。
实操建议：
- 必须用
<colgroup>包裹<col>，且每个<col>都设width属性（推荐写成<col width="150">，比 CSS 更稳） - 避免在
<th>或<td>上写width，IE11 可能根本不读第一行的样式 - Layui 等框架渲染后需手动补上
<colgroup>：在done回调里插入 DOM，不能靠初始 HTML - 动态 resize 表格时，IE11 不会自动重算
<col>宽度，得用 JS 重新设置col.style.width
Chrome/Firefox/Safari 下百分比列宽忽大忽小
根本不是浏览器 bug，而是 table-layout: fixed 要求三要素同时满足：显式 table 宽度、列宽定义落在第一行或 <col>、无 min-width/max-width 干扰。漏一条，整个表就退化回 auto 模式，列宽由内容撑开。
常见错误现象：
立即学习“前端免费学习笔记（深入）”；
-
table { width: 100%; table-layout: fixed; }写了，但没加<colgroup>，结果 Chrome 显示正常，Firefox 列宽全挤在一起 -
<col style="width: 40%">和<col style="width: 60px">混用，整表列宽计算失效，回退到 auto -
td { min-width: 80px; width: 25%; }—— Firefox 中min-width优先级高于百分比，直接覆盖
实操建议：
- 统一用像素值定义列宽（如
<col width="160"><col width="120">），避免混用单位 - 若必须响应式，改用 JS 监听
resize后动态改col.width，别指望媒体查询作用于<col> - 删掉所有单元格上的
min-width、max-width、vertical-align（尤其 Firefox 对后者敏感）
Android WebView 和旧版 Safari 列宽抖动或错位
这些环境对 <col> 的解析更严格，但对内联 width 支持反而差。典型表现是：首屏加载列宽正常，滚动后某列突然变窄；或 colspan 单元格导致后续列整体右偏。
关键原因：
-
<col>必须在<thead>之前出现，哪怕 DOM 顺序写在<tbody>后面，某些 WebView 也会忽略 -
colspan="2"的<th>如果没对应两个<col>，fixed 模式下会强制合并列轨道，破坏后续列对齐 - 父容器用了
transform或will-change，部分 Android WebView 会重置表格内部尺寸缓存
实操建议：
- 把
<colgroup>放在<table>开始后立即写，不要等 JS 注入 - 禁用
colspan，改用 CSS Grid 或 Flex 模拟表头合并效果 - 给父容器加
overflow: hidden，避免transform触发重绘异常
为什么 <col> 是最稳的列宽控制方式
它不依赖渲染顺序、不参与盒模型计算、不受内容溢出影响，是唯一被所有主流引擎在 fixed 模式下“提前锁定列轨道”的机制。比起在 <th> 上写 width: 20%，<col> 在 DOM 构建阶段就决定了列宽基准，连 SSR 渲染都可靠。
注意点：
-
<col>数量必须和实际列数一致，少一个，最后一列会被拉伸填充剩余空间 -
col.width是 HTML 属性，不是 CSS，所以不能用!important覆盖，也不能被 CSS-in-JS 工具提取 - 如果表格列数动态变化（比如后端返回字段不确定），必须用 JS 动态生成
<col>，不能靠初始模板硬写
复杂点在于：它看起来简单，但一旦嵌套在框架组件、SSR、或异步数据流里，<colgroup> 的插入时机和 DOM 位置稍有偏差，就会全盘失效。这点比写错一个 CSS 属性更难 debug。
