标准盒模型 content-box 下，width 仅指内容区宽度，实际宽 = width + 左右 padding + 左右边框；border-box 下，width 指总宽，padding 和边框从中扣除，内容区自动收缩。
标准盒模型 content-box 的尺寸怎么算？
当你写 width: 200px; padding: 15px; border: 3px solid #000;，在默认的 box-sizing: content-box 下，元素实际占位宽度是：
内容区宽 200px + 左右 padding（15×2 = 30px）+ 左右边框（3×2 = 6px）= 236px。
高度同理。margin 不参与盒子自身尺寸计算，但会影响它和邻居的距离。
- 容易踩的坑：用百分比布局时，比如两个
width: 50%的盒子并排，加了 padding 或 border 就会换行——因为总宽超了 100% - 适用场景：极少数需要“内容区域严格等宽”的旧系统适配，或配合 JS 动态读取
offsetWidth做精确计算（此时它返回的是含 padding + border 的总宽） - 兼容性：所有浏览器默认就是它，无需额外设置
怪异盒模型 border-box 的尺寸怎么算？
设 box-sizing: border-box; 后，同样的 width: 200px; padding: 15px; border: 3px solid #000;，元素最终渲染出来的**总宽度就是 200px**——padding 和 border 从这 200px 里“挤”出空间，内容区自动缩为 200 − 30 − 6 = 164px。
- 常见错误现象：“我明明设了 width: 100%，为什么盒子还是溢出容器？”——大概率是你忘了全局重置
box-sizing，导致某些子元素仍按 content-box 计算 - 实操建议：项目开头就加这条重置规则，一劳永逸
* { box-sizing: border-box; } - 性能影响：无。它只是改变了 CSS 解析逻辑，不触发重排或重绘
为什么推荐默认用 border-box？
因为人脑对“这个盒子就要占满父容器的 100% 宽度”有明确预期，而不是“这个盒子的内容区占 100%，再加 padding 和 border 就超了”。border-box 把复杂计算交给浏览器，你只管声明“我要多大”，不用手动减去 padding 和 border。
- 响应式开发中，
flex或grid容器里的子项如果混用两种 box-sizing，极易出现错位或截断 - UI 组件库（如 Ant Design、Element Plus）内部全部强制使用
border-box，如果你覆盖了它的样式却漏掉这一条，组件视觉就会失真 - 注意：
box-sizing不继承，所以即使父元素设了border-box，子元素仍需显式声明或靠通配符重置
content-box 还有必要存在吗？
有，但极少。比如你要做 canvas 绘图容器，JS 需要精确控制绘制区域大小，而 canvas.width 和 canvas.height 只反映 content 区域；此时若容器用了 border-box，就得手动减去 border/padding 才能对齐，反而增加出错概率。
立即学习“前端免费学习笔记（深入）”；
- 另一个真实场景：CSS 自定义属性（
--size）动态控制尺寸时，若同时用于 content 和 border-box 元素，计算逻辑会分裂，维护成本陡增 - 关键提醒：不要在同一个项目里“部分用 border-box、部分用 content-box”——除非你有完整文档记录每一处差异，否则半年后自己都看不懂为什么那个按钮突然变窄了
