offsetWidth/offsetHeight 返回元素的布局尺寸，含内容、内边距、边框，不含外边距和滚动条；为只读整数，受 display: none 影响而为 0，触发同步重排。

offsetWidth/offsetHeight 返回的是什么尺寸

它们返回的是元素的**布局尺寸**，包含内容、内边距、边框，但不包括外边距。这个值是只读的，且始终为整数（四舍五入到像素），即使 CSS 中设置了小数像素或百分比宽度。

常见误区：以为 offsetWidth 包含滚动条 —— 实际上它**不扣除滚动条宽度**（比如 overflow: scroll 时，offsetWidth 仍等于父容器设定的宽，而非可视内容区宽度）。

• 适用于需要知道“元素在页面中实际占位多大”的场景，例如做拖拽限制、对齐计算
• 受 display: none 影响：此时值恒为 0；而 visibility: hidden 不影响
• 触发重排（reflow）：首次访问会强制同步计算样式和布局，高频调用需防性能问题

clientWidth/clientHeight 和 offset 的关键差异

clientWidth 和 clientHeight 返回的是**内容可视区域尺寸**，即内容区 + 内边距，但**不包含边框、外边距，也不含滚动条所占空间**（注意：在某些浏览器中，滚动条宽度会被从 clientWidth 中减去）。

典型错误现象：clientWidth 比预期小了 17px —— 很可能是因为垂直滚动条占用了空间，而你没考虑它的存在。

• 适合用于计算可滚动区域大小、设置 scrollTop 边界、判断是否溢出
• 当元素有 overflow: hidden 时，clientWidth ≈ offsetWidth − 边框宽度 × 2
• 与 offset 不同，client 属性对 display: none 元素也返回 0，行为一致

offsetLeft/offsetTop 为什么常被误用

这两个属性返回的是元素**相对于其 offsetParent 的左/上偏移量**，不是相对于视口或文档的绝对坐标。很多人直接拿它做定位计算，结果在嵌套定位上下文中出错。

典型错误：给一个 position: relative 的子元素取 offsetTop，却忽略了它的父级恰好也是 position: relative —— 此时 offsetParent 就是那个父级，而非 。

• offsetParent 可能是最近的定位祖先（position 为 relative/absolute/fixed/sticky），也可能是 或
• 若元素或任意祖先设置了 transform，部分浏览器（如 Chrome）会令 offsetParent 变为 null，导致 offsetTop 返回 0
• 需要视口坐标时，应改用 getBoundingClientRect()，它不受 offsetParent 影响

什么时候该用 getBoundingClientRect() 而不是 offset/client

当你需要**精确到小数、脱离祖先定位依赖、同时获取全部边界信息**时，getBoundingClientRect() 是唯一可靠选择。它返回一个包含 top、left、right、bottom、width、height 的对象，单位为 CSS 像素（支持 subpixel）。

容易被忽略的一点：该方法返回的是**相对于视口（viewport）的坐标**，不是文档（document）。滚动后数值会变，这点和 offsetTop 完全不同。

• 适配缩放（zoom）、高 DPR 设备时更稳定，offset 和 client 在某些缩放比例下会取整失真
• 可直接用于 element.style.left = rect.left + 'px' 这类定位，但注意要加上 window.scrollX/window.scrollY 才能得到文档坐标
• 性能上比反复读取 offset 稍重，但现代浏览器已优化，单次调用无压力

const rect = element.getBoundingClientRect();
console.log(rect.left); // 相对于视口左边缘
console.log(rect.width); // 精确到小数，如 120.34
console.log(rect.top + window.scrollY); // 转换为文档 Y 坐标

真正复杂的不是 API 本身，而是你是否清楚当前要解决的问题属于哪个维度：是“它自己有多大”，还是“它在哪”，或是“用户能看到多少”。选错属性，后面所有计算都会漂移。