ie将padding/border计入width是为贴近设计师“设宽即占宽”的直觉，属历史性的怪异模式；w3c坚持width仅指content以保障逻辑一致性；box-sizing:border-box通过将width定义为border box总宽，统一了两种需求。
因为浏览器厂商在早期对 width 和 height 的语义理解不一致，W3C 标准与 IE 实现走了两条路，后来用 box-sizing 统一收口。
IE 为什么把 padding/border 算进 width 里？
IE5.5–6 在实现 CSS 时，把 width 解释为“用户想看到的盒子总宽”，更贴近设计师直觉——比如设 width: 200px，就真的占 200px，内边距和边框往里挤。这种模式叫“怪异模式（quirks mode）”，不是 bug，是历史选择。
- 它没有违背“元素要能被控制尺寸”这个核心需求
- 当时网页以表格布局为主，精确像素控件比语义清晰更重要
- 开发者写
div { width: 100%; padding: 10px; }，在 IE 里刚好填满父容器，很顺手
W3C 为什么坚持 width 只算 content？
标准模型把 width 定义为内容区尺寸，是为逻辑一致性：padding 是“内容的呼吸空间”，border 是“装饰层”，它们不该反向压缩内容。这更利于模块化、可复用的样式设计。
- 当你用
flex或grid布局子项时，width表达的是“内容期望占据的空间”，而非渲染后总占地 - 计算公式统一：
总宽 = width + padding-left + padding-right + border-left + border-right，所有部分职责分明 - 但代价是：写
width: 300px; padding: 20px; border: 1px solid;后，实际占位变成 342px，容易撑破容器
box-sizing: border-box 是怎么解决矛盾的？
它不改变渲染结果，只改 width/height 的绑定对象——从 content 区切换到 border box 边界。本质是把“计算权”交还给开发者，同时保留标准模型底层结构。
-
box-sizing: border-box下，width: 300px意味着“content + padding + border = 300px”，内容区自动收缩 - 现代项目几乎都加
* { box-sizing: border-box; }，但要注意<textarea></textarea>、<select></select>等原生控件会因此变矮，建议用html { box-sizing: border-box; } *::before, *::after { box-sizing: inherit; } -
calc()总是在box-sizing解析之后起作用，所以width: calc(100% - 40px); box-sizing: border-box;中，calc()输出的就是最终总宽
真正容易被忽略的点是：box-sizing 不影响 margin，也不影响 flex/grid 的主轴分配逻辑——它只管自己这一层的 width/height 如何解析。如果你在 flex 容器里给子项设了 flex: 1，再加 box-sizing: border-box，子项依然按剩余空间比例伸缩，只是内部 padding/border 不再额外撑开它。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
