content-box 下 width 仅指内容区宽度，不包含 padding 和 border；实际占用宽度为 width + 左右 padding + 左右 border。
box-sizing: content-box 时 width 真实含义是什么
默认就是 content-box，这时候 width 只管内容区宽度，不包含 padding 和 border。很多人误以为设了 width: 200px 元素就占 200px 宽，其实它最终占用的水平空间是：width + padding-left + padding-right + border-left-width + border-right-width。
常见错误现象：容器设了 width: 100%，又加了 padding: 16px，结果内容溢出或换行——因为总宽已超父容器 100%。
- 如果父容器宽度固定为
300px，子元素width: 100%+padding: 20px+border: 2px solid，实际占宽是300px + 40px + 4px = 344px -
max-width同样受此规则影响，它限制的也是内容区宽度，不是外边框总宽 - 百分比
width的计算基准始终是父容器的 content box 宽度，和父级 padding/border 无关
box-sizing: border-box 改变的是哪部分计算逻辑
border-box 不是“让 width 包含 border”，而是把 width 重新定义为“内容区 + 内边距 + 边框”的总宽。换句话说，你设的 width 值，就是元素最终在页面上占据的水平空间（不含 margin）。
使用场景：做响应式栅格、卡片布局、表单控件对齐时，能避免反复心算 padding/border 占位。
立即学习“前端免费学习笔记（深入）”；
- 设
width: 200px+padding: 10px+border: 3px solid，内容区实际只剩200px - 20px - 6px = 174px - 所有现代浏览器都支持，但 IE8+ 才支持
border-box，IE7 及更早版本只认content-box - 建议全局重置：
* { box-sizing: border-box; }，但注意<input>、<textarea></textarea>等表单元素在某些旧版 chrome 中可能因此高度异常，可单独重置为content-box
calc() 在盒模型计算中容易被忽略的细节
calc() 能帮你显式写出总宽表达式，但它本身不改变盒模型，只是动态算出一个值赋给 width 或其他属性。关键在于：它算出来的结果仍要按当前 box-sizing 规则解释。
常见错误现象：用 calc(100% - 32px) 减去 padding，却忘了 border 还没扣，导致依然溢出。
-
width: calc(100% - 32px);只减了 32px，如果还有左右 border 各 1px，还得再减2px - 单位必须严格：
calc(100% - 20px)合法，calc(100% - 20)报错 - 嵌套
calc()不被支持（如calc(calc(100% - 20px) / 2)），需扁平化
JavaScript 获取真实宽度时该读哪个属性
dom API 返回的尺寸取决于你问什么。想验证盒模型计算是否符合预期，不能只看 offsetWidth，得知道它到底包含了啥。
offsetWidth 是最接近“眼睛看到的宽度”的值：它等于元素的 border-box 总宽（含 border + padding + content），四舍五入到整数像素。但它不包含 margin，也不反映 css 中设置的 width 值本身。
-
clientWidth= content width + padding（不含 border、scrollbar、margin） -
offsetWidth= content width + padding + border（不含 margin，含 scrollbar 占位） - 用
getComputedStyle(el).width拿到的是 CSS 中声明的width值（如"200px"或"50%"），不是实际像素值 - 若元素有 vertical scrollbar 且
overflow-y: scroll，clientWidth会减去滚动条宽度；offsetWidth则不会（它把滚动条当内容区一部分）
复杂点在于：这些值还受缩放、字体渲染、subpixel 渲染影响，offsetWidth 四舍五入后可能和手动计算的 width + padding + border 差 1px——这不是 bug，是浏览器渲染层的正常行为。