table-layout: fixed 将列宽计算提前至首行渲染前，仅依据<col>或首行单元格width值确定列宽，后续各行强制对齐该轨道；需配合table显式width、避免混用min/max-width，并用word-break等控制溢出。
table-layout: fixed 怎么改变单元格的宽度计算逻辑
默认 table-layout: auto 会让浏览器等整张表（所有行、所有单元格）的内容都加载并测量完，才决定每列多宽——这不仅慢，而且不可控。而 table-layout: fixed 把列宽计算压缩到「第一行渲染前」：它只看 <col> 或首行 <th>/<td> 的 width 值，后续所有行都必须对齐这个轨道，不管里面塞的是 "12345678901234567890" 还是 <img src="huge.jpg">。
为什么 padding 和 word-break 在 fixed 模式下容易“失效”
不是真的失效，而是 fixed 模式下宽度被锁死，内容溢出时会直接挤压 padding 可视区域。常见表现是：明明写了 padding: 8px，但文字顶到边框，或右边 padding 看不见。
- 检查是否误加了
white-space: nowrap或overflow: hidden，它们会阻止换行，让内容硬挤进固定列宽 -
td默认盒模型不是border-box，建议显式加box-sizing: border-box - 长无空格文本（如 URL、哈希值）需配
word-break: break-all或overflow-wrap: break-word，否则 padding 区域会被视觉覆盖 - 仅靠
width不够：若列宽设为100px，但内容最小宽度被浏览器保护在约2%容器宽，实际可能远大于 100px
col 元素为什么比在 th 上写 width 更可靠
<col> 是唯一在 DOM 渲染前就定义列轨道的方式，不依赖首行结构、不受 colspan 干扰，且跨浏览器一致性高。而首行 <th width="30%"> 在 Android WebView 或旧 Safari 中，一旦混用 px 和 %，整张表可能悄悄回退到 auto 模式。
-
<col>的width值在所有现代浏览器中都被严格遵循 - 不要用
fr单位：<col style="width: 1fr">无效，只支持%、px、em等绝对/相对单位 - 动态更新表格内容后，
table-layout: fixed不会自动重读<col>；需手动触发重绘，例如table.style.width = table.offsetWidth + 'px'
table-layout: fixed 不生效的三个硬性条件
它不是开关，是规则集。漏掉任意一条，浏览器就自动降级回 auto，你看到的“列宽乱飘”其实是它根本没启动。
立即学习“前端免费学习笔记（深入）”；
-
<table>必须有明确的width（如width: 100%或width: 800px），否则无参照基准 - 列宽定义必须来自
<colgroup><col>或首行单元格，后续行的width属性全被忽略 - 不能在
<th>/<td>上混用min-width或max-width，尤其 Firefox 中它们会劫持百分比计算
最常被忽略的是动态场景：JS 插入新行、框架（如 Element Plus）重载表格后，列宽不会自动重算——没有 table.redraw() 这种方法，得靠强制重取 offsetWidth 触发。
