transform会让父元素成为新的包含块，子absolute元素的top/left等定位值按其缩放后的内容区计算，而非原始尺寸；fixed元素则降级为相对该父容器定位，修复需将其移出transform容器或改用sticky。
transform 会让父元素变成新的 containing block
只要父元素设置了 transform（哪怕只是 transform: translateZ(0)），它就不再是普通流中的“定位上下文”，而是被规范定义为子 position: absolute 元素的**包含块（containing block）**。这意味着子元素的 top、left、right、bottom 全部改按这个父容器的**当前渲染尺寸和坐标系**计算，而不是原始布局尺寸。
常见错误现象包括：
-
top: 0; left: 0的子元素没贴住父容器左上角，反而“缩进”一段距离 - 父容器
scale(0.8)后，子元素设top: 100px，视觉位置比预期高得多——因为这 100px 是在缩小后的父内容区里量的 - Chrome DevTools 的 Layers 面板中能看到该父元素被单独分层，提示“Transformed layer”
transform-origin 不是定位原点，别指望它修正 top/left
transform-origin 控制的是变形中心（比如 scale 或 rotate 绕哪转），它**不改变 absolute 子元素的定位参考点**。子元素的 top/left 始终以父容器**内容区左上角**为起点，而这个“左上角”已经因 transform 被重新映射了。
例如：transform-origin: center; transform: scale(0.8) 会让父容器视觉上缩小并居中，但子元素的 top: 0 仍从这个“缩小后的内容区左上角”开始量——不是原始尺寸的左上角，也不是 transform-origin 所在点。
立即学习“前端免费学习笔记（深入）”；
容易踩的坑：
- 误以为
transform-origin: 0 0能让子元素恢复像素对齐（实际无效） - 用像素值写
transform-origin: 20px 30px，但父容器宽高不固定时，基准会漂移 - 在调试时只改
transform-origin却没动transform或布局结构，问题依旧
fixed 定位也会被 transform 父容器劫持
当 position: fixed 元素的任意祖先设置了 transform，它就不再相对于视口定位，而是降级为相对于那个祖先元素——行为等同于 position: absolute。
典型场景：
- 外层
.wrapper { transform: translateZ(0); }为了开启 GPU 加速 - 内部
.nav { position: fixed; top: 0; left: 0; }结果卡在 wrapper 内部，随页面滚动
这不是浏览器 bug，是 CSS 规范明确要求的行为。触发条件还包括：filter、will-change: transform、backdrop-filter 等。
临时排查方法：
- 给疑似父容器加
outline: 1px solid red，对比边框与 fixed 元素实际位置 - 把 fixed 元素直接移到
下一级，看是否恢复正常
真正有效的修复路径只有两个方向
想让 absolute 或 fixed 元素摆脱 transform 父容器的影响，必须打破“它作为 containing block”这一层关系。没有中间态，只有实操选择：
- 把子元素**移出 transform 容器**：比如外层加一个
position: relative的 wrapper，子元素直接相对于它 absolute；或把 fixed 元素提到 body 直接子级 - 放弃依赖父容器定位，改用
transform自身对齐：例如子元素设top: 0; left: 0; transform: translate(50%, 50%)，再配合transform-origin调整锚点——但这本质是绕开定位系统，需手动控制视觉落点
用 calc() 手动补偿缩放比例（如 top: calc(100px / 0.8)）看似可行，但真实缩放值得靠 JS 读取 getComputedStyle(el).transform 解析矩阵，成本高且易出错。日常开发中，移出容器是最稳定、最易维护的做法。
