content-box下width/height仅控制内容区尺寸，padding和border额外叠加，导致实际总宽=width+左右padding+左右border；border-box则使width/height包含内容、padding和border，总尺寸恒定；margin始终独立于box-sizing计算。
content-box下width/height到底管什么
它只管内容区尺寸，padding和border全算“额外开销”。比如设width: 200px; padding: 15px; border: 2px solid #000;，内容区确实是200px，但元素实际总宽度是200 + 15*2 + 2*2 = 234px。这个值会直接影响父容器是否溢出、兄弟元素是否换行。
常见错误现象：在栅格系统里给.col加padding后布局错乱；用flex: 1的子项突然撑破容器；JS读取offsetWidth发现比CSS写的width大一截——基本都是没意识到content-box的“虚高”。
- 适用场景：需要严格控制文本或Canvas内容区像素尺寸时（如等宽字体排版、像素画渲染）
- 兼容性无问题，所有浏览器默认就是它
- 不要依赖它做响应式占位，除非你愿意每次改padding都重算一遍总宽
border-box为什么能“稳住”总尺寸
你写的width就是元素最外沿到最外沿的距离。padding和border不再往外撑，而是往里挤内容区。同样width: 200px; padding: 15px; border: 2px solid #000;，内容区自动缩为200 - 15*2 - 2*2 = 166px，总宽铁定是200px。
这正是现代项目普遍用* { box-sizing: border-box; }的原因：不用心算边框和内边距，写多少宽就占多少地方。
- 全局重置推荐写法：
* , *::before , *::after { box-sizing: border-box; } - 老项目改造时，优先在
.card、.input、.btn这类组件上显式加box-sizing: border-box - 某些原生控件（如Safari旧版
select）对border-box支持不稳，需单独加box-sizing: content-box兜底
margin为什么永远“不讲武德”
margin不参与任何box-sizing计算——无论content-box还是border-box，它都游离在盒子之外。设width: 300px; margin: 20px;，元素内容+padding+border加起来可能是300px，但实际水平占位是300 + 20*2 = 340px。
很多人误以为box-sizing: border-box能“包住margin”，结果用calc(100% - 40px)减去margin，发现还是溢出。那是因为100%是父容器内容区宽度，而margin占的空间根本不在这个百分比里。
- 要精确控制整体占位，必须显式处理margin：
width: calc(100vw - 40px); margin: 20px; - Flex/Grid布局中，用
gap替代margin更安全，它不计入单个子项尺寸 - JS测量真实占位时，别只看
offsetWidth，得加上getComputedStyle(el).marginRight等
什么时候必须退回content-box
不是所有场景都适合border-box。当你需要JS动态适配内容区尺寸（比如让<canvas></canvas>画布宽高严格匹配文字行高），或者复用依赖原始offsetWidth逻辑的老代码，硬切border-box会导致视觉偏移或计算错乱。
此时得局部覆盖：.canvas-wrapper { box-sizing: content-box; }，再用JS读取clientWidth减去getComputedStyle拿到的padding/border值，手动算出纯内容区大小。
- Canvas、SVG、
<pre class="brush:php;toolbar:false;"></pre>等对像素敏感的场景，content-box更可控 - 全局用了border-box后，某处真要content-box行为，必须显式写
box-sizing: content-box - 注意：
box-sizing不继承，子元素不会自动跟着变
实际占位永远由三部分叠加决定：box-sizing控制的内容+padding+border，再加上完全独立的margin。漏掉任意一块，计算就会失准。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
