content-box是w3c最初为保障内容宽度可预测而设定的规范契约，因ie怪异模式与标准模式分裂及海量存量页面兼容性压力，浏览器至今不敢更改默认值，故业界采用全局重置border-box的叠加补丁策略。
因为 CSS 1.0 规范就定义了 width 和 height 只控制内容区尺寸，content-box 不是“遗留 bug”，而是最初的设计契约——所有浏览器都照着这个契约实现，才有了后来的兼容性基础。
为什么早期规范选 content-box 而不是 border-box？
上世纪 90 年代末设计 CSS 盒模型时，网页以图文混排为主，开发者最常做的操作是：给一段文字加 padding 留白、加 border 做分隔线，但“这段文字本身要占多少宽度”必须可预测。如果 width: 200px 包含 padding 和 border，那每次改 padding 都得重新算 width，对表格布局和文本流极其不友好。
这种设计也贴合当时主流渲染逻辑：border 和 padding 是“装饰层”，内容才是“主干”。所以浏览器把 width/height 的语义锚定在内容区域，是最直接、副作用最小的选择。
IE 的“怪异模式”反而让 content-box 更难被替代
IE5 引入了所谓的“怪异模式（Quirks Mode）”，在该模式下它把 box-sizing 默认设为 border-box —— 这和所有其他浏览器（包括 IE6+ 标准模式）都不一致。结果就是：
- 老项目在 IE5/IE6 怪异模式下跑得好好的，一开标准模式就错位
- 开发者写 CSS 时不得不假设“IE 怪异模式 = border-box”，而其他浏览器 = content-box
- W3C 无法强行改默认值，否则等于宣布所有已存在的 content-box 页面“集体失效”
这导致 content-box 被事实固化为标准行为，哪怕后来大家发现它更难用。
现代浏览器为何仍不敢改默认值？
哪怕到了 2026 年，Chrome、Firefox、Safari 依然坚持默认 content-box，根本原因就一条：没有一个浏览器敢承担破坏存量页面的风险。你随便搜一个 2010 年前的老 CMS、论坛模板或政府网站，几乎全是靠心算 padding + border 来对齐的。一旦改默认值：
- 数以亿计的静态 HTML 页面会突然错行、溢出、卡片重叠
- CDN 缓存的旧 CSS 会和新浏览器行为冲突，连 debug 都无从下手
- 前端构建工具（如 PostCSS 插件）依赖默认模型做尺寸推导，全链路要重验
所以行业选择用 * { box-sizing: border-box; } 显式覆盖，而不是动规范根基——这是兼容性演进里最典型的“叠加补丁”策略。
真正容易被忽略的点是：即使你全局用了 border-box，flex-basis 和 grid-template-columns 里的长度值，依然按 content-box 语义解析。这不是 bug，是模型分层决定的——盒模型管单个元素，布局模型管空间分配，两者没绑定关系。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
