content-box是CSS2.1默认但反直觉的盒模型，width/height仅指内容区，实际尺寸需叠加padding和border；其缺乏box-sizing标准支持、不兼容现代布局（Flex/Grid）、无法全局重置且易受第三方样式干扰。
content-box 是默认但反直觉的尺寸逻辑
CSS2.1 的盒模型只有一种计算方式：content-box。这意味着当你写 width: 200px; padding: 10px; border: 1px solid #000;，元素实际占用的水平空间是 200 + 10×2 + 1×2 = 222px。这个规则在固定布局中尚可推演，但在响应式场景下极易失控——尤其是嵌套容器叠加 padding 和 border 后，宽度溢出、换行错位、媒体查询断点偏移等问题频发。
开发者必须手动减去 padding 和 border 来“凑”出想要的 content 宽度，比如用 calc(100% - 22px)，既脆弱又难维护。而现代开发中，绝大多数人期望的是：我设了 width: 100%，它就真的占满父容器可用空间（含 padding 和 border 内部消化）。
没有 border-box 标准支持，兼容性方案粗糙
CSS2.1 规范里根本不存在 box-sizing 属性。IE6/7 的“怪异模式”虽默认用类似 border-box 的行为，但那是非标准、不可控的意外，并且仅限于 IE。要跨浏览器统一行为，只能靠 hack：
- 对所有元素加
* { width: auto !important; }并配合特定 DOCTYPE 切换渲染模式（已淘汰） - 用 JavaScript 动态计算并重设 width（性能差、不可靠）
- 依赖 reset.css 强制覆盖部分表单元素（不彻底、易遗漏）
这些方法无法解决根本问题：它们不能改变盒模型的底层语义，只是在视觉上“模拟”。直到 CSS3 引入标准化的 box-sizing，才让 border-box 成为可声明、可继承、可组合的正式能力。
立即学习“前端免费学习笔记（深入）”；
缺乏对现代布局上下文的适配能力
CSS2.1 盒模型的设计前提，是页面由 float + clear 或 table + position 拼凑而成。它没考虑 Flexbox 容器中 flex-basis 与 box-sizing 的交互，也没定义 Grid Track 尺寸如何受子项 box-sizing 影响。结果就是：
- 在
display: flex容器中，flex-basis默认按content-box解析，但开发者常误以为它会包含 padding —— 导致等分布局时 item 实际宽度不一致 - Grid 的
minmax(200px, 1fr)中，200px指的是 content 区域最小值，若子项设了padding，内容区可能被压缩变形 - 使用
resize: both的元素，在拖拽后尺寸计算仍遵循旧模型，容易出现滚动条闪现或内容裁切
这些问题不是 bug，而是 CSS2.1 模型在语义层面与现代布局原语脱节的必然结果。
全局重置成本高，且无法局部隔离
想在项目中统一用 border-box，CSS2.1 下只能逐个选择器覆盖，比如：
.card { box-sizing: border-box; }
.form-input { box-sizing: border-box; }
.table-cell { box-sizing: border-box; }
这种写法漏掉一个 selector 就可能引发布局断裂。而现代写法 * { box-sizing: border-box; } 或更安全的 *:before, *:after { box-sizing: border-box; } 能一次性覆盖全部上下文——包括伪元素生成的内容框，这对使用 ::before 做装饰性边框或图标的技术至关重要。CSS2.1 无法提供这种简洁、可靠、可预测的批量控制能力。
真正棘手的不是“怎么写”，而是“写了之后是否确定生效”：当第三方组件、内联样式、浏览器默认样式表混入时，box-sizing 的优先级和继承链在 CSS2.1 环境中几乎无法推演。现代浏览器的层叠逻辑和开发者工具的 computed 样式面板，才让这种控制变得可观察、可调试、可信任。
