父元素用scale后子absolute元素top/left算不准，因其创建新包含块导致定位锚点漂移；推荐用inset替代并注意兼容性，或避免父级transform、重构为flex/grid。
父元素用scale后，子absolute元素的top/left为什么算不准
因为父元素加了transform: scale()，它会创建新的包含块（containing block），子元素的top/left就不再相对于初始视口或最近的position: relative祖先，而是相对于这个缩放后的父容器内容区——而该区域的尺寸、坐标系都已被缩放“扭曲”。你看到的错位，本质是定位锚点漂移了。
用inset替代top/left是最直接的修复方式
inset不依赖传统包含块计算逻辑，它直接锚定到当前包含块的边缘（比如父容器的border box），缩放时行为更稳定。但必须注意写法和兼容性：
- 写
inset: 1rem auto auto 1rem，别混用left: 50%——后者会覆盖inset的左值，行为不可控 - 旧浏览器不支持
inset，得用@supports not (inset: 0)包裹降级写法：top: 16px; left: 16px; -
inset在position: absolute和position: fixed下都有效，但fixed在原生缩放下仍有底层渲染限制
避免父容器创建新包含块是治本之策
只要父元素带任意transform（包括translateZ(0)、scale(1)），就会触发新包含块。排查和规避方法很实际：
- 用 Chrome DevTools 的 Layers 面板看哪些元素被单独分层，标红的就是嫌疑对象
- 临时加
outline: 1px solid red，对比元素边框与实际视觉位置，暴露“布局盒 vs 渲染盒”偏差 - 若必须保留父级
scale，把需要精确定位的子元素移出，改由一个无transform的祖先来承载
真要缩放，别用浏览器Ctrl+/Cmd+，改用主动scale控制
浏览器原生缩放对position: fixed和含transform父容器的子absolute元素是硬伤，JS无法可靠修正。可控解法只有一种：
立即学习“前端免费学习笔记（深入）”；
- 把
transform: scale(1.2)应用在最外层容器（如#app），并同步设transform-origin: 0 0或50% 50% - 确保所有依赖定位的子元素都处于这个统一缩放树下，避免混合使用原生缩放+主动缩放
- 禁用
user-scalable=yes以外的viewport设置，否则iOS下vh等单位会进一步失准
scale，而是多层嵌套的transform + absolute结构——这种情况下，错位是必然的，重构为flex或grid往往比打补丁更省时间。 
