元素最终渲染宽高由width/min-width/max-width共同约束，块级非flex/grid元素可手算，其余须用getBoundingClientRect()实测；box-sizing决定width是否含padding/border；offsetWidth不含margin且不响应transform，而getBoundingClientRect()包含视口真实像素。
直接看结论：元素最终渲染宽度 = width（或自动计算值） + 左右padding + 左右border + 左右margin，但前提是没被min-width/max-width截断；高度同理。这个公式只在块级、非flex/grid子项中“可手算”，其他场景得靠getBoundingClientRect()实测。
box-sizing 决定 width/height 是内容区还是总宽高
默认box-sizing: content-box时，你写的width: 200px只是内容区域宽度，实际占位还要加padding和border；设成box-sizing: border-box后，width: 200px就代表“内容+内边距+边框”的总宽度（不含margin）。
容易踩的坑：
- 全局没重置
box-sizing，导致表单控件、卡片等加了padding后莫名撑破容器 - 临时切回
content-box时忘了清除继承，子元素意外变宽 -
border-box下写width: 100%再加padding，仍能严丝合缝；但content-box下会溢出
min/max-width/height 会覆盖 width/height 的设定值
最终尺寸不是width说了算，而是由width、min-width、max-width三者共同约束得出——它取的是“在边界内最接近目标值”的结果。
立即学习“前端免费学习笔记（深入）”；
常见现象：
-
width: 200px; min-width: 300px;→ 实际宽度是300px，不是200px -
width: auto; max-width: 400px;→ 内容撑到400px就停，再多也卡住 - 图片设
max-width: 100%但父容器width为auto，此时实际宽度取决于内容宽度和max-width谁更小
offsetWidth 和 getBoundingClientRect().width 不是一回事
offsetWidth返回的是元素自身盒模型测量值（含padding+border，不含margin），而getBoundingClientRect().width返回的是该元素在视口中的真实像素占据量，包含transform缩放、设备像素比等影响。
关键区别：
-
offsetWidth在display: none时返回0，getBoundingClientRect()也是0；但visibility: hidden下两者都正常 - DOM刚插入就调
getBoundingClientRect()，可能拿到未 layout 的旧值，得包一层requestAnimationFrame -
offsetWidth无法反映transform: scale(0.5)后的实际视口宽度，getBoundingClientRect()可以
flex/grid 容器里的子项不能套用传统宽高公式
一旦元素是flex或grid子项，它的最终尺寸就由容器的布局算法决定：flex-basis、flex-grow、grid-template-columns等参数优先级高于width，手动套用width + padding + border公式基本失效。
这时候必须：
- 用
getBoundingClientRect()实测，别猜 - 检查
flex-shrink是否为0——否则即使设了width: 300px也可能被压缩 - 注意
min-width: 0对 flex 子项的影响：默认min-width: auto会阻止收缩，加了min-width: 0才真正“听 flex 分配”
最易被忽略的一点：动态内容（比如富文本、折叠面板）的高度不是测一次就能一劳永逸的，DOM结构变化后必须重新触发 layout 并再次测量，否则getBoundingClientRect()返回的还是旧值。
