默认width不包含padding和border，仅指内容区宽度；启用box-sizing: border-box后，width才包含padding和border，内容区自动压缩。
看 width 值到底包不包含 padding 和 border
最直接、最可靠的区分方式——不用查文档、不用试渲染，只看 CSS 里写的 width 语义是否“含内边距和边框”。
标准盒模型（box-sizing: content-box）中，width: 200px 指的是内容区宽度；
怪异盒模型（box-sizing: border-box）中，width: 200px 就是左 border 到右 border 的总宽。
常见误判：看到元素实际占位比 width 大，就以为是“样式没生效”，其实只是 content-box 在按规则叠加。
用 offsetWidth 验证实际渲染宽度最靠谱
光看 CSS 规则容易被继承或层叠干扰，直接读 DOM 属性更可靠。
在控制台执行 el.offsetWidth 返回的是包含 padding 和 border 的像素值（不含 margin），再对比你写的 width 值：
若 el.offsetWidth > parseInt(getComputedStyle(el).width) → 大概率是 content-box
若两者相等 → 基本确定是 border-box
注意：getComputedStyle(el).width 返回带单位的字符串，必须用 parseInt() 转数字再比
这个方法绕过了样式来源（行内、style 标签、外链）、浏览器默认行为、DOCTYPE 触发模式等干扰项，直击渲染结果本身。
全局重置时 * { box-sizing: border-box; } 会踩哪些坑
虽然这是现代项目的通用写法，但不是无副作用的：
- 表单控件如 input[type="search"]、旧版 Safari 中的 select 或 button，可能因 border-box 导致内边距挤压、文字截断或点击区域异常
- 某些第三方 UI 库（如 Ant Design 早期版本）已对组件显式设了 box-sizing: border-box，若你在全局重置后又局部覆盖为 content-box，反而造成不一致
- *::before 和 *::after 伪元素也受该规则影响，若它们依赖原始尺寸计算（比如用 content 生成图标并靠 width/height 控制大小），可能错位
推荐写法：* , *::before , *::after { box-sizing: border-box; }，再对表单控件单独兜底：input, select, textarea, button { box-sizing: content-box; }
margin 为什么永远不参与盒模型计算
margin 在两种模型中地位完全一致：它始终在盒子外部，不计入 width 或 height，也不受 box-sizing 影响。
常见误判就是把外边距合并（margin collapse）现象当成盒模型差异，其实那和 box-sizing 无关。
父子元素间 margin-top 合并，在 content-box 和 border-box 下表现一模一样
相邻块级元素垂直方向的 margin 折叠，也与盒模型类型无关
真正影响布局尺寸的，只有 width/height + padding + border 这三者的归属关系
所以调试时如果发现元素“莫名变宽”，先别急着改 margin，优先检查 box-sizing 和 padding/border 是否被意外叠加
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
