为什么CSS fixed在transform容器内变成absolute

fixed元素在transform父容器中“失效”是CSS规范行为而非bug：只要父级设置非none的transform（如translateZ(0)）、filter、opacity<1等，就会创建新包含块，使fixed退化为相对该父级定位；修复应移出DOM至body或改用sticky。

fixed元素在transform父容器里“失效”是规范行为，不是bug

只要父级元素设置了 transform（哪怕只是 transform: translate(0, 0)），它的子元素若设了 position: fixed，就会自动降级为相对于该父容器定位，视觉上表现得像 position: absolute。这不是渲染异常，而是 CSS 规范明确要求：任何创建新 containing block 的属性（transform、filter、opacity、will-change 等）都会让 fixed 失去对视口的绑定。

怎么快速确认是不是transform导致fixed失效

打开开发者工具，逐层往上检查祖先节点的 computed styles：

1. 看是否有 transform: none 以外的值（包括 translateZ(0)、scale(1) 这类“无感变形”）
2. 检查 opacity 是否小于 1
3. 留意 will-change: transform 或 filter 是否存在
4. 右键元素 → “Scroll into view”，观察 fixed 元素是否随父容器一起滚动或被裁剪——如果是，基本锁定问题源头

为什么加了transform就触发这个行为

transform 非 none 会强制创建新的 containing block 和 stacking context。而 position: fixed 的定义是“相对于初始包含块（通常是视口）定位”，一旦其路径上出现新的 containing block，浏览器就必须重新计算定位参考系——它不再找视口，而是找离它最近的那个新 containing block 的边界。

常见陷阱：

1. UI 框架（如 Ant Design、Element Plus）常悄悄加 transform: translateZ(0) 触发 GPU 加速，这足以让内部所有 fixed 子元素失效
2. 父容器本身没写 position，但加了 transform，照样成为包含块——不需要显式 position: relative
3. Chrome/Firefox 严格遵循该规范；IE11 不执行此规则，所以 fixed 在 IE 里仍正常，反而容易掩盖问题

真正能用的修复方式只有两种

别试图用 JS 动态补偿偏移量，也别指望 transform: translate(0, 0) 重置坐标系——它依然创建 containing block。

1. 把 fixed 元素从 transform 容器中提级，挂到一个干净的、无 transform / filter / opacity 的祖先节点下（比如外层 .app 或 body）
2. 如果 DOM 结构不能动，就放弃 fixed，改用 position: absolute + 显式 position: relative 的父容器，并确保该父容器自身不带任何触发 containing block 的属性

最易被忽略的一点：即使你只对父容器加了 transform，它的所有后代（无论嵌套多深）只要用了 fixed，都会受影响——这个作用域是继承式的，不是局部的。