table-cell 的 width 常“不起作用”是因为其宽度由表格布局算法统一分配，受 table-layout（auto/fixed）、border-collapse、定义及父容器约束，非独立生效。
table-cell 的宽度在不同浏览器中表现不一致，根本不是渲染引擎“算错”，而是你没控制住它的计算前提——它不认 margin，不响应 width 的常规逻辑，且受 border-collapse 和父级 table-layout 双重钳制。
为什么 table-cell 的 width 常常“不起作用”
浏览器对 display: table-cell 元素的宽度计算，本质是参与整张表的列宽分配，而非独立生效。即使你给单个 div 写了 width: 120px，只要它在 table 或 display: table 容器里，这个值就只是“建议”，最终由表格布局算法（auto 或 fixed）统一分配。
-
table-layout: auto（默认）下，所有table-cell宽度由内容最长项决定，你设的width可能被完全忽略 -
table-layout: fixed下，width才真正起效，但必须满足三个条件：父table有明确width、列宽定义落在第一行或<colgroup></colgroup>、单元格上不能混用min-width/max-width - IE11 对
table-cell的width支持极弱，只认<col width="120">这类显式像素值，CSS 中的width: 120px可能无效
border-collapse 如何悄悄改写你的宽度预期
border-collapse: separate 和 border-collapse: collapse 不仅影响边框样式，更直接改变 table-cell 的盒模型行为和可调参数范围。
- 在
separate模式下：border-spacing控制单元格间距，padding控制内容到边框距离，margin完全无效（规范强制忽略） - 在
collapse模式下：border-spacing彻底失效，padding是唯一可控的留白手段；但边框合并后可能视觉上“吃掉”部分padding，尤其当边框粗细不一时 - Safari 和旧版 Android WebView 对
collapse模式下的 padding 渲染更保守，相同数值下看起来更窄；Chrome 则倾向撑满
跨浏览器稳定的 table-cell 宽度控制方案
想让 table-cell 在 Chrome/Firefox/Safari/IE11/Android WebView 中宽度基本一致，必须放弃“单点调节”，转为结构+规则双控。
- 统一用
<colgroup><col width="160"></colgroup>定义列宽，比内联style="width: 160px"更可靠，尤其对 IE11 和 WebView - 父
table必须设width（如width: 100%或具体像素），否则table-layout: fixed退化为auto，宽度立刻失控 - 删掉所有
table-cell元素上的min-width、max-width、margin—— 它们在多数浏览器中要么被忽略，要么在 Firefox 中优先级异常高，覆盖百分比计算 - 内容溢出时，用
overflow: hidden+text-overflow: ellipsis替代强行缩放宽度，避免因字体渲染差异导致的临界换行
动态更新后宽度不重算，这是最常被漏掉的环节
JS 插入新行、修改 table-cell 文本、或切换响应式断点后，浏览器不会自动重读 <col> 或第一行宽度——它认为“列宽已定”。结果就是内容变长了，但列宽卡死不动，视觉上严重错位。
- 不要依赖框架的
reload()或resize()方法，它们不一定触发列宽重计算 - 安全做法是手动“扰动”：执行
table.style.width = table.offsetWidth + 'px'，强制浏览器重新取值并应用fixed规则 - 若用 Layui，需在
done回调后立即调用table.resize()（Layui 2.8+）；Element Plus 表格则建议重建固定列逻辑，而非仅刷新数据
真正麻烦的不是写不对那几行 CSS，而是 table-cell 的宽度永远不是孤立变量——它被 table-layout、border-collapse、<col>、内容长度、甚至父容器的 padding 同时牵制。少满足一个条件，整套控制就失效。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
