offsetWidth始终等于边框+内边距+内容宽度（含滚动条），与box-sizing声明无关；它返回整像素值，反映元素实际占位宽，且读取时必触发重排。
offsetWidth 在 box-sizing: border-box 和 content-box 下的计算差异
它不看 box-sizing 声明本身，而是直接按浏览器最终渲染的盒模型规则算：边框 + 内边距 + 内容宽度（含滚动条，不含外边距）。所以即使你写了 box-sizing: border-box，offsetWidth 依然包含 border 和 padding；而 box-sizing: content-box 下它也照样包含——因为 offsetWidth 本来就不区分这个声明，它只反映“当前元素占位的实际像素宽”。
常见错误现象：offsetWidth 比你 CSS 里写的 width 大很多，以为是 JS 算错了，其实是忘了 border/padding 也被计入了。
- 如果你设了
width: 200px; padding: 10px; border: 2px solid #000;，无论box-sizing是什么，offsetWidth都是200 + 2×10 + 2×2 = 224 -
box-sizing: border-box只影响元素内容区如何收缩，不影响offsetWidth的取值逻辑 - 滚动条存在时（如内容溢出），
offsetWidth通常包含滚动条宽度（Chrome/Firefox 行为一致，但 Safari 在某些缩放下可能有微小偏差）
getBoundingClientRect() 和 offsetWidth 返回值为什么经常不等
根本原因是：一个基于布局坐标系（带小数、受 transform 影响），另一个基于整像素渲染占位（四舍五入、忽略 subpixel 渲染细节）。
使用场景：做精确对齐（比如 tooltip 跟随鼠标）、动画起始位置计算时，getBoundingClientRect() 更可靠；而判断“这个 div 是否撑开了父容器”，用 offsetWidth 更直观。
立即学习“前端免费学习笔记（深入）”；
-
offsetWidth总是返回整数（浏览器内部四舍五入到最近像素） -
getBoundingClientRect().width可能带小数，尤其在 zoom ≠ 1 或使用 subpixel 定位时 - 如果元素有
transform: scale(0.8)，offsetWidth不变，但getBoundingClientRect().width会缩小 - 父级有
overflow: hidden且子元素溢出时，offsetWidth仍返回自身完整占位宽，而getBoundingClientRect()返回的是相对于视口的裁剪后坐标
IE8–11 中 offsetWidth 的兼容性陷阱
IE 的 offsetWidth 在 table 相关元素（<table>、<code><td>、<code><tr>）上行为不稳定：有时不包含 border，有时又多算一行高度对应的 padding，尤其在 <code>border-collapse: collapse 下。
性能影响：IE 下频繁读取 offsetWidth 触发 layout thrashing 更严重，因为其 layout 引擎更敏感。
- 避免在循环中反复读取
offsetWidth，尤其针对<td> 元素<li>IE8 不支持 <code>getBoundingClientRect()对 SVG 元素的返回，但offsetWidth对 SVG 元素始终返回 0（除非显式设了 width/height 属性） - 如果元素 display 为
none，所有 IE 版本都返回 0 —— 这点和现代浏览器一致，但容易被忽略 -
offsetWidth必然触发重排（layout），没有例外 - 若只需内容区尺寸，优先用
el.clientWidth（含 padding，不含 border/scrollbar） - 滚动条宽度建议用缓存策略：首次访问时用
document.documentElement.offsetWidth - document.body.offsetWidth估算，并存到模块变量里复用 - 不要试图用
getComputedStyle(el).borderLeftWidth解析 px 值来累加 —— 单位可能是em、rem或百分比，解析成本高且易错
用 getComputedStyle() 模拟 offsetWidth 但排除滚动条？做不到
很多人想用 getComputedStyle(el).width 加上 padding 和 border 手动算出 offsetWidth，再减掉滚动条宽。但问题在于：getComputedStyle() 返回的 width 是 CSS 值（如 "200px" 或 "auto"），不是实际渲染像素；而且滚动条宽度无法通过标准 API 稳定获取（clientWidth 和 offsetWidth 的差值在不同系统/缩放下不可靠）。
真实场景：需要在 modal 弹窗打开前预估内容尺寸，又不想触发重排。
最常被忽略的一点：offsetWidth 包含「浏览器强制添加的最小宽度」。比如一个空 <div> 设了 <code>min-width: 0，在某些旧版 Chrome 中仍可能返回 2px —— 这不是 bug，是渲染引擎对可点击区域的兜底处理，无法绕过。
