getBoundingClientRect()每次调用返回值不同，因其基于当前视口实时计算，受滚动、缩放、DOM变更、CSS transform/position等影响；非静态偏移量，需缓存或节流调用，并注意跨iframe及祖先transform干扰。
getBoundingClientRect 返回值为什么每次调用都不同
因为 getBoundingClientRect() 返回的是元素相对于**当前视口（viewport）** 的实时坐标，只要页面滚动、缩放、DOM 变动或 CSS transform/position 改变，结果就会变。它不缓存，也不“记住”初始位置。
常见错误现象：top 突然变成负数、left 跳变、在 scroll 事件里反复计算却没更新 UI —— 很可能误以为它是静态偏移量。
- 使用场景：做 tooltip 跟随鼠标、下拉菜单对齐、拖拽锚点定位、滚动吸顶判断
- 不要在非必要时机频繁调用（比如
requestAnimationFrame里无条件重算），尤其在移动端，会触发强制同步布局（layout thrashing） - 如果只是想获取“初始渲染时的位置”，应在 DOM ready 后、首次滚动前调用并缓存；若需持续跟踪，请搭配
scroll或resize事件，但记得节流
JavaScript 修改元素位置后 getBoundingClientRect 不立即生效
DOM 写操作（如改 style.left、classList.add）和读操作（如调用 getBoundingClientRect()）之间如果没有浏览器重排（reflow）触发，读到的仍是旧值。
典型错误：改完 element.style.transform = 'translateX(100px)' 紧接着就调 getBoundingClientRect()，结果 left 没变。
立即学习“Java免费学习笔记（深入）”；
- 最稳妥做法：强制触发重排，例如读一个会触发 layout 的属性，如
element.offsetHeight或getComputedStyle(element).transform - 更推荐方式：把读操作放到
requestAnimationFrame回调里，确保在下一帧绘制前读取最新布局 - 注意：CSS transition/animation 过程中调用
getBoundingClientRect()返回的是当前帧渲染值，不是目标值，别拿它去判断动画是否结束
定位不准？检查 offsetParent 和 CSS transform 的干扰
getBoundingClientRect() 的结果看似“绝对”，其实受祖先元素 offsetParent 和 CSS transform 影响极大——但它本身不告诉你这些上下文，容易误判。
常见错误现象：弹窗总偏左 20px、tooltip 在缩放页面里错位、fixed 元素的 top 值异常小。
- 当任意祖先有
transform、perspective、filter或will-change时，该祖先成为新的 containing block，getBoundingClientRect()的坐标系仍以 viewport 为基准，但视觉位置已偏移 - 若需“相对父容器”的坐标，别直接减
parent.getBoundingClientRect()，应先用element.offsetParent判断实际定位上下文，再结合offsetTop/offsetLeft（注意：它们不包含 transform） - fixed 定位元素调用
getBoundingClientRect()返回的是相对于 viewport 的值，但若页面有transform: scale()，结果会被缩放影响（Chrome 表现明显，Firefox 不同）
跨 iframe 场景下 getBoundingClientRect 返回坐标无效
如果目标元素在另一个 <iframe></iframe> 里，直接调用其 getBoundingClientRect() 返回的是**该 iframe 视口内的坐标**，不是主页面 viewport 的坐标，强行叠加会错位。
错误写法：iframe.contentDocument.querySelector('#el').getBoundingClientRect()，然后直接赋给主页面某元素的 style.top。
- 必须手动换算：先获取 iframe 自身在主页面中的
getBoundingClientRect()，再把子 iframe 内元素的top/left加上 iframe 的top/left - 注意 iframe 的
scrollLeft/scrollTop—— 如果 iframe 内部也滚动了，还得减去它的滚动偏移 - 跨域 iframe 无法访问其
contentDocument，此时只能靠 postMessage 协商，由子 frame 主动上报自身元素位置
真正麻烦的从来不是 API 怎么写，而是你默认它返回的是“你想当然的那个坐标系”。多一层 console.log 打印祖先元素的 getComputedStyle 和 offsetParent，比查文档快得多。
