默认 width/height 仅指内容区，不包含 padding 和 border；设 width: 200px 实际可能占 240px，因 box-sizing 默认为 content-box；改用 border-box 后 width 包含内容、内边距与边框，更符合设计习惯且避免计算错误。
默认情况下 width/height 只算内容区，不是整个盒子
这是最常踩的坑：你写 width: 200px，结果元素在页面里占了 240px 宽，根本没溢出也没报错，就是“莫名变宽”。原因很简单——浏览器默认用的是 box-sizing: content-box，此时 width 和 height 仅代表内容区域尺寸，不包含 padding 和 border。
常见错误现象：
- 表单输入框加了
padding: 12px和border: 1px solid #ccc，设了width: 100%却撑破父容器 - 卡片组件设了
width: 300px，加上内边距和边框后实际宽度超 320px，导致响应式断点失效 - 用 Flex 布局时子项宽度计算错乱，明明 flex-basis 是 200px，但视觉上明显更宽
用 box-sizing: border-box 改写计算逻辑
设置 box-sizing: border-box 后，width 就真的等于“内容 + 内边距 + 边框”的总宽度（不含 margin），高度同理。这更符合设计稿标注习惯，也大幅降低手动减法计算的出错率。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 项目初始化时就全局重置：
*, *::before, *::after { box-sizing: border-box; } - 不要只对部分元素设
border-box，否则容易漏掉伪元素或第三方组件内部样式 - 注意：IE8+ 支持该属性，现代项目无需兼容更低版本
外边距 margin 不参与“自身宽高”，但决定布局空间
margin 永远不计入元素自身的 width/height 计算，但它会实实在在影响元素在文档流中占据的空间，尤其在块级上下文中容易引发“看不见的间隙”问题。
关键细节：
- 相邻块级元素的垂直
margin会发生合并（collapsing），最终间距取两者较大值，不是相加 -
margin可为负值，常用于微调定位或实现“吸边”效果，但慎用于响应式场景（负 margin 在小屏下易导致内容被截断） - 水平方向的
margin: auto能触发块级元素居中，但前提是元素有明确width（否则auto无效）
计算公式必须分清“渲染尺寸”和“占用空间”
一个元素的「渲染尺寸」（即 getBoundingClientRect().width 返回值）= width + 左右 padding + 左右 border（当 box-sizing: content-box）；而它在布局中「实际占用的空间」还要加上左右 margin。
所以真正影响其他元素位置的，是后者。比如：
.item {
width: 200px;
padding: 10px;
border: 2px solid #000;
margin: 15px;
}
它的渲染尺寸是 200 + 20 + 4 = 224px，但左右共占据 224 + 30 = 254px 的横向空间。
最容易被忽略的一点：当你用 JavaScript 动态读取元素宽度（如 offsetWidth）时，返回值已是包含 padding 和 border 的完整渲染尺寸——它不区分 content-box 还是 border-box，只反映最终画到屏幕上的像素数。
