核心区别在于width/height是否包含padding和border：标准模型（box-sizing: content-box）中仅指content区域，怪异模型（box-sizing: border-box）中则包含content+padding+border；可通过getcomputedstyle(el).boxsizing或offsetwidth与width对比验证。
标准盒模型和IE怪异盒模型的核心区别，只在 width 和 height 这两个属性的语义上——前者只管 content，后者管的是 content + padding + border。
怎么看当前用的是哪种盒模型？
最直接的办法是查元素的 box-sizing 值：
-
box-sizing: content-box→ 标准模型（浏览器默认值） -
box-sizing: border-box→ 怪异模型行为（注意：不是 IE 专属，所有现代浏览器都支持）
别光看 CSS 规则——继承、层叠或重置可能干扰判断。更可靠的是在控制台执行：el.style.boxSizing 或 getComputedStyle(el).boxSizing。如果返回空字符串，说明没显式设置，那就按默认 content-box 处理。
为什么 offsetWidth 比写的 width 大？
这是标准模型的典型表现。比如：
div {
width: 200px;
padding: 15px;
border: 3px solid #000;
}
此时 el.offsetWidth 返回 236（200 + 15×2 + 3×2），因为 offsetWidth 永远包含 padding 和 border，而 width 在标准模型里只算 content。
- 若你期望
offsetWidth === 200，就得加box-sizing: border-box - 若你改了
padding却发现盒子变宽了，大概率漏写了box-sizing -
margin永远不参与这个计算，它不影响offsetWidth，也不受box-sizing控制
全局重置成 border-box 有什么坑？
写 * { box-sizing: border-box; } 确实省心，但要注意：
- 原生表单控件（如
input[type="search"]、textarea）在某些浏览器里会因border-box错位或高度异常 - 第三方 UI 库（比如旧版 Bootstrap）可能已内部处理过盒模型，重复重置反而破坏布局
- SVG 元素、
button等替换元素对box-sizing的响应不一致，建议单独测试
稳妥做法是：*, *::before, *::after { box-sizing: border-box; }，再针对性地给 input, select, textarea, button 单独设回 content-box。
真正容易被忽略的点是：盒模型差异从来不会导致样式“不生效”，它只会悄悄让尺寸计算偏离预期——尤其在响应式布局、栅格系统或动态插入内容时，padding 和 border 的叠加效应会被放大。验证不能只靠眼睛看，得用 offsetWidth / offsetHeight 读真实像素值。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
