box-sizing: content-box下width仅指内容区，padding和border额外叠加使总宽增大；border-box下width包含content、padding和border，内容区自动收缩以保证总宽恒定。
box-sizing: content-box 和 border-box 的实际效果差异
关键不是“哪个更标准”，而是 width 和 height 这两个属性在不同 box-sizing 下到底管什么。默认是 content-box，此时你写的 width: 200px 就只是内容区域宽 200px；换成 border-box 后，这 200px 就得“匀出”空间给 padding 和 border，内容区自动收缩。
常见错误现象：改了 padding，发现盒子整体变宽了——大概率忘了加 box-sizing: border-box；或者用 JS 读 offsetWidth 得到 236，但 CSS 写的 width 是 200，就以为“算错了”，其实是标准模型本该如此。
-
offsetWidth永远包含padding+border，和box-sizing无关 -
getComputedStyle(el).width返回的是计算后的内容宽度（content-box下 = 你写的值，border-box下 -
margin不参与任何box-sizing计算，它始终额外占位
如何可靠判断当前元素用的是哪种盒模型
别只看 CSS 文件里有没有写 box-sizing，继承、重置、层叠都可能覆盖。最稳的方式是直接查运行时值：
getComputedStyle(el).boxSizing —— 返回 "content-box" 或 "border-box"；如果返回空字符串，说明没显式设置，按默认 content-box 处理。
另一个快速验证法：对比 el.offsetWidth 和 parseFloat(getComputedStyle(el).width)。若前者明显更大（比如差出 30px），且元素有 padding 或 border，基本就是 content-box。
- 注意
el.style.boxSizing只能读内联样式，漏掉外部 CSS 就会误判 - 某些 UI 库（如旧版 Bootstrap）可能已全局设过
box-sizing，再叠加重置容易冲突
全局设 * { box-sizing: border-box } 的实际坑点
虽然省事，但不是无脑开箱即用。原生表单控件在部分浏览器（尤其是 Safari 和旧版 Chrome）里会因 border-box 导致高度错乱或文字截断；textarea、input[type="search"]、button 都容易中招。
稳妥做法是：
- 先写
* { box-sizing: border-box; } - 再单独重置：
input, select, textarea, button { box-sizing: content-box; } - SVG 元素不响应
box-sizing，别白费力气设
第三方组件库（如 Ant Design、Element Plus）通常内部已处理好盒模型，额外全局重置反而破坏其布局逻辑。
为什么盒模型问题总在响应式或动态插入时才暴露
因为静态页面里 padding 和 border 的叠加效应不明显；一旦涉及 calc(100% - 20px)、栅格列宽计算、或 JS 动态插入带 padding 的元素，尺寸偏差就会被放大——比如一个 width: 100% 的容器，里面塞了个 padding: 16px 的子元素，默认 content-box 下它就真超出了父容器。
真正难察觉的点是：它从不报错，也不让样式“失效”，只是悄悄让像素值对不上。验证不能靠肉眼估，必须用 offsetWidth / getBoundingClientRect() 读真实像素。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
