will-change: transform 会使 fixed 元素失效，因其提前创建新包含块；will-change: filter 同理，但 opacity 安全；可通过 devtools 定位并用 createportal 或 will-change: auto 临时修复。
will-change: transform 会让 fixed 元素失效，因为它等效于已应用 transform
只要 will-change 声明了 transform，浏览器就会提前创建新的包含块（containing block），哪怕元素当前的 transform 计算值仍是 none。这不是 bug，是规范行为：CSS 要求“即将变化的属性”所对应的布局上下文必须提前确立。
常见错误现象包括：
- fixed 元素突然随父容器滚动，像 absolute 一样定位
- 在 iOS Safari 中完全消失或错位到视口外
- DevTools 的 Computed 面板里
transform显示none，但定位仍异常
此时别查自己写的样式——第三方组件（如 Ant Design 的 Drawer、el-dialog）内部常默认加 will-change: transform 做动画预告，你没写，但它写了。
哪些 will-change 值会触发包含块创建
只有部分 will-change 关键字会干扰 fixed 定位：
-
will-change: transform—— 最常见，直接等效于transform: translateZ(0) -
will-change: filter—— 等效于filter: blur(0)，同样创建新包含块 -
will-change: opacity—— 不会 创建新包含块，可安全用于 fixed 元素加速 -
will-change: scroll-position—— 已被弃用，Safari 完全不支持，且对 fixed 元素无效
注意：will-change: contents 或 will-change: auto 不触发该问题；但写死 will-change: transform 在 CSS 里，等于长期占用合成层，内存不释放。
如何验证并临时绕过 will-change 干扰
用 Chrome DevTools 快速确认是否是 will-change 搞的鬼：
- 选中失效的 fixed 元素 → Elements 面板右上角按住 Shift 连续点箭头，逐层跳父节点
- 每到一层，在 Computed 面板搜索
will-change，看是否为transform或filter - 找到后，临时加
will-change: auto !important到该祖先上，fixed 恢复即确认
若无法修改祖先样式（比如来自 UI 库），最稳解法是用 createPortal（React）或 Teleport（Vue）把 fixed 元素挂到 document.body 下，彻底脱离干扰链。
替代方案：用 opacity 替代 transform 做性能预告
如果你加 will-change 只是为了防动画卡顿（比如弹窗淡入），优先换用：
will-change: opacity;
原因很实在：
-
opacity不会改变包含块，fixed 定位完全不受影响 - 现代浏览器对
opacity动画自动提层，效果和transform接近 - 避免了
translateZ(0)在某些安卓 WebView 中引发的图层爆炸
真正需要位移动画时，必须显式写 transform: translateX(0)，再配合动态 will-change: transform（JS 控制 set/clear），而不是靠 CSS 静态声明。
容易被忽略的一点：iOS Safari 对 will-change 的处理更激进——哪怕只在某个临时弹层上声明，也可能导致整个页面 fixed 元素短暂失锚。所以，不要把它当开关用，而要当成一个需精确控制生命周期的提示信号。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
