实际渲染总宽度由width、min-width、max-width共同约束，并受padding、border、margin及box-sizing影响；块级非flex/grid子项可用盒模型推算，其余场景必须用getBoundingClientRect()实测。
直接看结论：实际渲染总宽度 ≠ 你写的 width，它由 width、min-width、max-width 共同约束，再叠加 padding、border、margin，但前提是元素是块级且非 flex/grid 子项；其他情况必须用 getBoundingClientRect() 实测。
box-sizing 决定了 width 的含义
默认 box-sizing: content-box 时，width: 200px 只是内容区宽度，实际占位还要加左右 padding 和 border；设成 box-sizing: border-box 后，width: 200px 就代表“内容 + 内边距 + 边框”的总宽度（不含 margin）。
- 全局没重置
box-sizing，表单控件或卡片加了padding后容易撑破容器 -
border-box下写width: 100%再加padding，仍能严丝合缝；content-box下会溢出 - 临时切回
content-box时忘了清除继承，子元素可能意外变宽
min/max-width 会覆盖 width 的设定值
最终尺寸不是 width 说了算，而是三者共同约束的结果：取“在边界内最接近目标值”的那个。
-
width: 200px; min-width: 300px;→ 实际宽度是300px -
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或visibility: hidden下都返回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: 100px，在flex: 1容器里也可能被拉伸或压缩 - 此时手算完全失效，唯一可靠方式是实测
getBoundingClientRect() - 注意：绝对定位元素若脱离文档流，其
getBoundingClientRect()坐标可能不参与父容器尺寸计算，但自身包围盒仍可被正确读取
真正容易被忽略的是：即使你搞清了所有盒模型规则，只要元素处于 flex/grid 上下文、有 transform、含异步加载图片、或被第三方框架锁死样式，就别信任何“手算”，老老实实走 getBoundingClientRect() + 坐标极值法——尤其是当你要测溢出内容的真实视觉高度时。
