box-sizing: content-box 是默认行为，width 仅指内容区宽度，不包含 padding 和 border；box-sizing: border-box 则使 width 包含 padding 和 border，总宽严格等于声明值；margin 始终不参与盒模型计算，需单独规划。
box-sizing: content-box 是默认行为，但 width 只管内容区
浏览器默认用 content-box，意味着你写的 width: 200px 就是内容区的宽，不包含 padding 和 border。只要加了内边距或边框，元素实际占位就会变大。
- 常见错误现象：栅格列突然换行、卡片溢出容器、响应式断点失效——往往就是没意识到
padding: 16px让一个width: 100%的 div 实际宽超出了父容器 - 使用场景：极少数需要 JS 精确读取内容区尺寸时（比如 Canvas 绘图适配），保留
content-box更直接 - 参数差异：
offsetWidth返回的是总宽度（含 padding + border），而getComputedStyle(el).width返回的是你声明的width值（即内容区）
box-sizing: border-box 让 width 真正代表“占多大地方”
border-box 把 padding 和 border 向内挤，内容区自动收缩，最终元素总宽严格等于你写的 width 值。
- 常见错误现象：全局重置后，第三方 UI 库组件高度/宽度错位——因为库内部可能已设
box-sizing: border-box，而你自己的元素还是默认content-box，混用导致盒模型不一致 - 实操建议：新项目直接在 CSS 入口加
* { box-sizing: border-box; }；老项目改造优先从表单、卡片等高频复用模块开始，显式加box-sizing: border-box - 性能影响：无运行时开销，纯渲染时计算逻辑切换，IE8+ 全支持，移动端无顾虑
margin 始终游离在外，box-sizing 完全不管它
无论用 content-box 还是 border-box，margin 都不参与盒模型尺寸计算——它永远是盒子外部的空间。
- 容易踩的坑：写
width: 300px; margin: 20px;，以为占位是 300px，实际水平空间是300px + 40px，常导致横向滚动或布局错位 - 关键提醒：
box-sizing只管 content/padding/border 三层，margin必须单独规划，不能靠它“兜底” - 调试技巧：用浏览器开发者工具 hover 元素时，看盒模型图示最外层虚线框才是真实占位边界，那里面才包含
margin
老项目切换要小心 offsetWidth 类 JS 计算逻辑
如果页面里有 JS 直接依赖 offsetWidth 或 clientWidth 做布局判断（比如动态调整列宽、弹窗定位），强行全局切 border-box 可能让数值突变。
立即学习“前端免费学习笔记（深入）”；
- 典型问题：原来
width: 200px; padding: 10px; border: 2px下offsetWidth === 224，切完变成200，JS 误判容器不够宽，触发错误折叠 - 稳妥做法：先搜索代码中所有
offsetWidth、clientWidth、getBoundingClientRect()调用点，确认是否隐含了对content-box行为的假设 - 兼容方案：局部切换时，用
calc()或getComputedStyle()显式减去padding和border，保持 JS 逻辑不变
真正容易被忽略的，是那些没写 box-sizing 却引入了多个第三方 UI 库的页面——不同库各自声明不同，同一级元素盒模型不统一，查起来毫无头绪。
