content-box 是浏览器默认的盒模型，width/height 仅作用于内容区，padding 和 border 会额外增加总尺寸；仅当全局或父级设为 border-box 时才需显式声明以还原默认行为。
content-box 是默认行为，不用额外声明
只要不显式设置 box-sizing，所有元素天然就是 content-box。它不是“开启传统逻辑”，而是浏览器的原始计算方式——width 和 height 仅作用于 content 区域，padding 和 border 会向外撑开总尺寸。
什么时候必须显式写 content-box？
只有在以下场景才需要主动写 box-sizing: content-box：
- 父元素或全局重置用了
* { box-sizing: border-box }，而你某个组件（比如自定义input或卡片）需要还原默认行为 - 第三方 UI 库内部强制设了
border-box，你想局部覆盖 - 调试时临时对比两种模型差异，用开发者工具快速切回原生表现
注意：content-box 不会“修复”布局问题，反而可能让 width: 100% + padding 导致溢出——这是它的本意，不是 bug。
content-box 下的 width 计算容易踩的坑
常见错误现象：div 设了 width: 300px，加了 padding: 20px 和 border: 2px solid，结果实际占满 344px 宽度，超出父容器。
原因在于：总宽度 = width + 左右 padding + 左右 border + 左右 margin。这个公式里任何一项非零都会让视觉尺寸变大。
使用建议：
- 做像素级精确控制（比如对接设计稿标注）时，先确认设计师是否按
content-box量的尺寸 - 表单元素如
input、textarea默认是content-box，但它们的border和padding渲染行为在不同浏览器有细微差异，需单独测试 - 避免混用：同一页面中部分元素用
border-box、部分用content-box，会导致尺寸预期混乱，尤其在 flex/grid 布局中
content-box 和 border-box 混用时的兼容性影响
两者本身无兼容性问题（所有现代浏览器都支持），但混合使用会放大维护成本：
- 团队协作时，新人很难一眼判断某元素的
width到底指什么 - 响应式断点计算变得不可靠：比如
max-width: 600px的容器里放两个width: 50%的content-box元素，加上 padding 后可能换行 - 某些 CSS 框架（如 Bootstrap 5+）已彻底移除对
content-box的适配假设，直接按border-box编写内部尺寸逻辑
真正需要 content-box 的地方极少，多数时候是误以为“传统=正确”，其实只是历史遗留行为——它保留的是计算逻辑，不是布局优势。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
