border-box是生产项目事实标准，因它使width/height表示总占位尺寸，避免padding/border导致的溢出、换行、对齐错位；content-box仅在遗留系统、Canvas/SVG等特殊场景被动保留。
生产环境几乎只用 border-box，content-box 仅在极少数隔离场景下被动保留，不是“选”，而是“默认用哪个、例外怎么压”。
为什么 border-box 是生产项目的事实标准
它解决的是布局中“尺寸失控”的根本矛盾：设计稿标注的 200px 宽度，就是组件外框总宽；你写 width: 200px，它就真占 200px，不管加多少 padding 或 border。这直接规避了三类高频问题：
- 栅格系统中多个
width: 25%元素因 padding/border 溢出换行 - Flex 容器里子项
flex-basis被content-box的min-width: auto拉宽，意外触发换行 - 表单控件（如
input）与文字对齐时，边框和内边距导致高度不一致
所有主流 UI 框架（Tailwind、Bootstrap、Ant Design）都默认全局启用 border-box，不是为了炫技，是工程化兜底的必然选择。
content-box 在哪不得不留？
它不是“可选方案”，而是“必须绕开的兼容包袱”或“刻意隔离的边界”。真实场景极少，但一旦出现就得手动覆盖：
立即学习“前端免费学习笔记（深入）”；
- 对接遗留系统，对方 CSS 强依赖
content-box行为（比如某段老代码靠width精确控制 Canvas 内容区，改了会错位） - 封装
resize: both的可拖拽textarea，用户直觉是“拉宽 = 内容区变宽”，此时设box-sizing: content-box更符合交互预期（但需额外处理padding溢出） - 某些 SVG 容器组件，要求
width必须严格等于 viewBox 内容区域，不能被 border/padding 吞掉
这些情况必须显式写 box-sizing: content-box，且要加注释说明原因——否则后续维护者大概率会误删。
全局重置必须覆盖伪元素
只写 * { box-sizing: border-box; } 是危险的。CSS 伪元素（::before、::after）是独立渲染节点，通配符不生效，会导致它们仍走默认 content-box，引发布局偏移（比如按钮图标错位、卡片阴影异常）。
正确写法是：
*,
*::before,
*::after {
box-sizing: border-box;
}这是现代项目起步时的必做动作，漏掉一个 ::after 就可能埋下难复现的视觉 bug。
调试时怎么看生效没？
别猜，直接看 DevTools：
- 选中元素 → 右侧「Computed」面板 → 搜
box-sizing，确认值是border-box - 再对比「Styles」里的
width和「Computed」里的width：若两者相等，说明border-box生效；若「Computed」值更大，说明被content-box撑开了
最常被忽略的点：父容器用了 border-box，但某个子组件的 scoped 样式或第三方库样式又把 box-sizing 改回了 content-box，这种嵌套覆盖很难肉眼发现。
