display: table 触发表格布局算法，完全覆盖标准盒模型，width、height、padding、margin 行为异于常规；table-cell 宽度由整行内容、table-layout 和显式 width 共同决定，margin 无效，box-sizing 几乎无用，仅 table-layout: fixed 下首行 width 才具决定性。
display: table 触发表格布局算法，盒模型行为被覆盖
会。display: table 不是“微调”盒模型，而是完全切换到表格渲染上下文——此时 width、height、padding、margin 的作用逻辑和块级/行内元素完全不同，标准盒模型计算规则基本失效。
表格单元格（display: table-cell）尤其典型：它的宽度由整行所有单元格内容、table-layout 设置（auto 或 fixed）、以及显式 width 共同博弈决定，不是简单叠加 padding + border。
-
margin在table/table-cell上完全无效（浏览器静默忽略） -
padding仍生效，但只影响单元格内部内容位置，不参与外部尺寸分配 -
border-collapse: collapse会让相邻边框合并，此时 border 宽度不叠加，box-sizing失去意义 -
width在table-cell上只是“建议值”，最终可能被压缩或拉伸以填满表格行
为什么 box-sizing 对 display: table-cell 几乎没用
box-sizing 控制的是“width 和 height 到底算哪几层”，但前提是这些属性能参与尺寸计算——而 table-cell 的宽度根本不由单个元素的 width 主导，它服从整行的表格自动分配算法。
即使你写：td { width: 100px; padding: 20px; border: 5px solid #000; box-sizing: border-box; }，最终渲染宽度仍可能远大于或小于 100px，因为表格引擎会优先保证所有 td 加起来撑满 table 宽度。
立即学习“前端免费学习笔记（深入）”；
- 设
table-layout: fixed后，第一行th/td的width才真正起决定作用 - 此时
box-sizing: border-box仅影响该单元格内部 content 区域的压缩，不影响整行分配结果 - 垂直方向的
height同样不可靠，min-height比height更可控
display: table 布局常见翻车点
用 display: table 模拟网格或居中时，容易因尺寸不可控导致响应式断裂或文字换行异常。
- 嵌套多层
table/table-row/table-cell会放大计算复杂度，Chrome DevTools 的 Layout 面板常显示 “Layout Shift” 高风险 -
vertical-align在table-cell中有效，但在table或table-row上无效——很多人误以为能控制整行对齐 - Flex/Grid 出来后，
display: table已无必要用于布局；仅在真正需要语义化表格结构（如数据报表）时才保留 - 移动端 Safari 对
table-layout: fixed的兼容性偶有 bug，建议加min-width: 0防止列溢出
替代方案比硬调 display: table 更可靠
如果目标是居中、等高列或响应式栅格，直接用 Flex 或 Grid，它们的尺寸逻辑清晰、可预测，且支持 box-sizing 和媒体查询无缝协作。
例如：想让几个卡片高度一致且水平居中，不要写：
.container { display: table; width: 100%; }
.item { display: table-cell; vertical-align: middle; }
换成：
.container { display: flex; align-items: center; flex-wrap: wrap; }
.item { flex: 1 1 200px; min-height: 100px; }
前者依赖表格算法黑盒，后者每个尺寸都可调试、可打断点、可动画。
表格布局的“不可控感”不是 bug，是设计使然——它本就为结构化数据服务，不是通用布局工具。强行用它做 UI 布局，等于拿螺丝刀当锤子用，拧得越用力，越容易滑丝。
