box-sizing 是唯一控制盒模型尺寸计算逻辑的开关，决定 width/height 指代 content 区（content-box）还是含 border 的总宽（border-box），影响所有元素渲染前的基础尺寸解析。
box-sizing 是唯一控制盒模型行为的开关
CSS 盒模型没有“多种类型”，只有两种尺寸计算逻辑：由 box-sizing 决定的 content-box（标准）和 border-box（替代）。它不是布局模型（如 Flex、Grid），而是每个元素渲染前的**基础尺寸解析规则**——所有块级、行内替换元素都绕不开它。
常见错误现象：
– 明明设了 width: 300px，元素却撑出父容器；
– 给卡片加 padding: 16px 后，横向滚动条突然出现；
– 响应式中用 width: 50% 的子项，在加 border 后总宽超过 50%。
-
box-sizing: content-box（默认）：width/height 只管 content，padding 和 border 往外加 -
box-sizing: border-box：width/height 指的是“从左 border 到右 border”的总宽，内容区自动收缩 - margin 在两种模型中都不参与 width/height 计算，这点永远不变
为什么现代项目几乎都该用 border-box
不是“更先进”，而是它让尺寸预期可预测。当你写 width: 100% + padding: 20px + border: 1px，你真正想要的通常是“这个盒子刚好填满父容器”，而不是“内容区填满，再额外加 42px”。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 全局重置推荐：
* { box-sizing: border-box; }—— 但注意：它不作用于svg、input[type="button"]等原生控件，个别需单独覆盖 - 若项目已大量依赖
content-box行为（如旧版 Bootstrap 3 的 grid 类），不要全局强切，改用 scoped class 局部迁移 - 嵌套时警惕：父元素
border-box，子元素又显式写box-sizing: content-box，会导致子项尺寸“突然变大”，调试时容易漏看
标准模型没被淘汰，但适用场景极窄
它不是过时规范，而是特定需求下的工具。W3C 从未废弃 content-box，只是 border-box 成为了响应式开发的事实标准。
必须保留 content-box 的真实场景：
- 封装纯内容容器组件，要求
width严格等于内部文本渲染宽度（比如代码高亮行号栏） - 对接某些老 UI 库或 iframe 嵌入页面，其 JS 尺寸测量逻辑硬编码了标准模型
- 模拟表格单元格的弹性伸缩行为 —— 此时用
display: table-cell比强行套content-box更可靠
别被“IE盒模型”这个词带偏
“IE盒模型”是历史叫法，源于 IE5.5–6 在怪异模式下的默认行为。如今它早已是 W3C 标准的一部分，box-sizing: border-box 在 IE8+、所有现代浏览器中完全支持，移动端无兼容问题。
真正容易被忽略的一点：
– 它只影响元素自身的尺寸计算逻辑，不影响 Flex/Grid 的分配方式；
– 它不改变 margin 行为，也不影响定位（position）的参考系；
– 它不能解决父容器未设 width 导致的子项塌陷问题——那是另一个层级的问题。
