will-change本身不导致fixed失效，真正原因是祖先元素的transform、filter、opacity
因为 will-change 本身不改 fixed 行为，但它常和真正触发定位降级的属性（如 transform）一起出现，而浏览器对两者的响应机制不同：一个只是提示，另一个直接创建新 containing block —— 真正让 fixed “飘走” 的从来不是 will-change，而是它旁边的 transform: translateZ(0) 或 opacity: 0.99。
will-change 不会单独导致 fixed 失效，但会放大父级问题
will-change: transform 写在 fixed 元素自身上，浏览器大概率忽略（滚动时它的 transform 值根本没变），控制台还会报警告：will-change: transform is deprecated for non-transforming elements。但它若写在 fixed 元素的**父容器**上，就危险了——尤其当该父容器**已经**有 transform、filter 或 opacity 时，will-change 会加速合成层创建，让原本“半失效”的 fixed 变成彻底卡死在父容器里。
- 现象：导航栏突然随页面滚动、模态框只显示在某个
.wrapper右下角 - 验证方法：DevTools 中选中 fixed 元素 → Elements 面板右键 → Inspect rendering layers，看它是否被包进某个父层的图层树里
- 别查
will-change本身，重点查它父级的 computedtransform和filter值是否非none
fixed 元素“飘走”的真实触发条件
只要 fixed 元素的任意祖先（哪怕隔了 5 层）满足以下任一条件，它就不再锚定视口，而是锚定那个祖先：
-
transform值不为none（包括translateZ(0)、scale(1)、rotate(0deg)） -
filter值不为none（哪怕blur(0)或opacity(1)） -
opacity小于1（常见于 UI 库默认设opacity: .99） -
will-change值为transform、scroll-position、opacity等可合成属性（注意：will-change: auto无效，will-change: initial才能清除）
这些属性单独存在就足以破坏 fixed；will-change 只是常和它们共存，容易被误认为“元凶”。
怎么安全地用 will-change 配合 fixed 元素
如果确实需要动画（比如滑出抽屉、淡入弹窗），且该元素是 fixed 定位，必须把 will-change 控制在最小作用域：
- 只加在**动画目标元素自身**上，绝不在其父容器或
body上写死will-change: transform - 动画开始前动态设置：
el.style.willChange = 'transform' - 动画结束回调中立刻清除：
el.style.willChange = 'auto'（不是''，空字符串会被忽略） - 若元素初始无
transform，先加transform: translateZ(0)再配will-change，否则浏览器可能直接跳过图层创建 - 移动端尤其警惕：Android 4.4–6.0 WebView 中，长期挂着
will-change: transform会导致 GPU 图层持续分配不回收，几秒后 OOM 黑屏
修复时最容易漏掉的细节
很多人删掉 transform 后 fixed 还是不恢复，是因为干扰源不止一层：
- uni-app 或 Vue 框架中，
transform，得查到 DOM 根节点 - iOS Safari 中，
overflow-scrolling: touch也会让 fixed 退化为 absolute，需配合-webkit-overflow-scrolling: auto关闭 - 键盘弹出后 fixed 错位，不是样式问题，是 WebKit 主动剥离锚定关系，此时任何 CSS 优化都无效，唯一可靠入口是
focusin事件 +setTimeout(() => {}, 0)延迟重算位置 - 用
inset: 0替代top: 0; right: 0; bottom: 0; left: 0，避免某些旧引擎因 width/height 计算误差导致 fixed 裁剪
真正要盯住的永远是 DOM 层级和祖先样式链，而不是盯着 will-change 本身反复加删。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
