transform: translateZ(0)会让fixed元素“飘走”，因其在iOS WebKit和部分Android WebView中强制创建新堆叠上下文，使fixed脱离viewport定位而被钉死在局部坐标系；需删掉祖先transform、将fixed直挂body、设最大z-index并避免overflow:hidden等干扰。
硬件加速开启后，position: fixed 元素错位、消失、抖动或被截断，不是 CSS 写错了，是合成层（compositing layer）和堆叠上下文（stacking context）在底层冲突。
为什么 transform: translateZ(0) 会让 fixed 元素“飘走”
iOS WebKit 和部分 Android WebView 中，transform（包括 translateZ(0)）会强制创建新的 stacking context 和 containing block。一旦 fixed 元素的任意祖先（哪怕只是 body 或父容器）加了它，fixed 就不再相对于 viewport 定位，而是被“钉死”在那个局部坐标系里——视觉上就是突然偏移、透明、或随页面滚动。
- 常见诱因：
transform: translateZ(0)、opacity: 0.99、will-change: transform、filter（除opacity外） - 检查路径：用 DevTools 的 Layers 面板看
fixed元素是否出现在 “Composited Layers” 中；若它没单独成层，反而更安全 - 别给
html、body或包含fixed的 wrapper 加任何transform
如何让 fixed 元素真正挂载到 viewport
必须切断它与所有干扰性祖先的层级绑定，确保其 containing block 是 viewport 本身：
- 把
fixed元素直接插入<body>下，避开任何带transform/filter/opacity < 1的父容器 - 显式设置
z-index: 2147483647（最大安全整数），避免被中间 stacking context 截断 - 删掉
html和body上的overflow: hidden、height: 100%、position: relative—— 这些会误导 WebKit 重算 viewport 边界 - 禁用原生
alert()/confirm()：弹窗会冻结 WebCore 渲染线程，导致fixed层重绘失败
Android WebView 中的闪烁与残留怎么压
Android 硬件加速更粗放，GPU 纹理缓存容易错乱，尤其当 fixed 和 overflow: scroll 容器嵌套时，表现为滚动后白块、顶部闪现、按钮残留：
立即学习“前端免费学习笔记（深入）”；
- 移除非必要元素的
will-change: transform，并在动画结束回调中设el.style.willChange = 'auto' - 避免
fixed和overflow: scroll在同一 DOM 路径共存；如必须，给fixed的直接父容器加transform: none !important - Java 层兜底：过渡动画前临时切软件渲染
webView.setLayerType(View.LAYER_TYPE_SOFTWARE, null)，结束后再切回LAYER_TYPE_HARDWARE - 启用离屏预光栅化（Android 5.0+）：
webSettings.setOffscreenPreRaster(true)
比 translateZ(0) 更稳的替代方案
现代项目应优先绕开 fixed 的合成陷阱，而非硬刚：
- 简单吸顶场景（如导航栏）改用
position: sticky+top: 0，它原生支持 GPU 加速且无抖动，iOS 15.4+/Chrome 99+ 支持良好 - 必须用
fixed时，组合使用backface-visibility: hidden+transform: translateZ(0)双保险触发合成层，但只加在目标元素自身 - 慎用 JS 模拟：监听
scroll+requestAnimationFrame动态设transform: translateY(${window.scrollY}px)，仅用于复杂联动场景
最易被忽略的一点：Native View 与 HTML fixed 层级完全不互通。iOS 原生侧用 addSubview: 叠加 Banner 到 WKWebView 上方，H5 里写 z-index: 99999 的遮罩也盖不住——这种跨上下文遮挡，只能靠原生层统一管理层级顺序。
