标准盒模型与怪异盒模型的根本区别在于width/height属性的定义范围：前者仅指内容区尺寸，后者包含内容区、内边距和边框；分别对应box-sizing: content-box和border-box。
标准盒模型和怪异盒模型的计算方式不同，根本原因不是浏览器“故意搞错”，而是历史演进中两种设计哲学的碰撞：一个是语义优先（W3C标准），一个是直觉优先（IE早期实现）。
content-box 是 W3C 的语义化选择
W3C 把 width 和 height 定义为纯内容区尺寸，逻辑上更干净——padding 和 border 属于“装饰层”，不该侵入 content 的度量。这种分离让内容流、字体排版、行高计算等底层机制更可控。但代价是：写 width: 200px 后加 padding: 16px，盒子实际变宽了，布局容易意外溢出。
border-box 是 IE 的直觉化妥协
IE5.5 当年把 width 当作“你看到的整个框的宽度”，用户拖动调整大小时，直接感知的就是外沿尺寸。这种做法省去了开发者心算 padding+border 的步骤，尤其适合表格布局、固定栅格等场景。现代浏览器用 box-sizing: border-box 支持它，并非兼容旧 IE，而是承认这种模式在 UI 组件开发中更高效。
为什么不能统一？关键在继承与重置风险
如果强行全局切换，默认行为就变了，以下情况会出问题：
立即学习“前端免费学习笔记（深入）”；
-
input[type="search"]在 Safari 中设border-box后可能文字被裁切 - 某些 SVG 元素（如
<rect>）忽略box-sizing，值仍按 content-box 解析 - 第三方库（如旧版 Ant Design）内部已用
content-box做像素对齐，重置后按钮高度错位 -
getComputedStyle(el).width返回的字符串值，在border-box下仍是 content 区宽度（不是总宽），容易误读
验证时别只看 DevTools 的“Computed”面板
那个面板显示的是最终渲染尺寸，但不告诉你它是怎么算出来的。真正可靠的判断方式是：
- 查
getComputedStyle(el).boxSizing—— 返回"content-box"或"border-box" - 对比
el.offsetWidth和parseFloat(getComputedStyle(el).width)：若前者更大，说明是content-box（因为 offsetWidth 总含 padding+border） - 注意：margin 永远不参与这两种模型的 width/height 计算，它只影响外部间距
最易被忽略的一点：盒模型差异从不报错，它只是悄悄让 100% - 20px 的计算结果和你预期差几个像素——这种偏差在 flex wrap、grid gap 或动态插入 DOM 时会被指数级放大。
