硬加速下position: fixed元素错位消失，因合成层与堆叠上下文冲突；ios中祖先触发新stacking context致fixed脱离viewport；android中gpu纹理缓存错乱致闪烁残留；native与html层级不互通需原生层加至scrollview。
硬加速开启后，position: fixed 元素在 iOS WKWebView 和部分 Android WebView 中频繁错位、消失或被截断，不是 CSS 写错了，是合成层（compositing layer）和堆叠上下文（stacking context）在底层打架。
iOS WKWebView 中 fixed 元素突然“飞走”或变透明
根本原因是：WebKit 为 position: fixed 创建独立合成层时，若其任意祖先元素意外触发了新的 stacking context（比如加了 transform: translateZ(0)、opacity: 0.99 或 will-change: transform），fixed 元素就会被“钉死”在那个局部坐标系里，不再相对于 viewport 定位。
实操建议：
- 删掉所有无实际动画需求的
transform: translateZ(0)、perspective、backface-visibility: hidden - 给 fixed 元素显式设置
z-index: 2147483647（最大安全整数），避免被中间 stacking context 截断 - 检查
html和body是否有overflow: hidden、height: 100%或position: relative—— 这些会误导 WKWebView 重算 viewport 边界 - 禁用
alert()/confirm()：原生弹窗会冻结 WebCore 渲染线程，导致 fixed 层重绘失败；改用 HTML 自研弹窗 +pointer-events: auto
Android WebView 中 fixed 元素闪烁、白块或滚动残留
Android 4.0+ 默认开启硬件加速，但 WebView 的图层管理比 iOS 更粗放。当页面存在大量 overflow: scroll 容器嵌套 fixed 元素，或 canvas 高频重绘 + will-change 同时存在时，GPU 纹理缓存容易错乱，表现为局部花屏、滚动后 fixed 栏残留、顶部白块闪现。
实操建议：
- 对非必要动画元素，移除
will-change: transform并在动画结束回调中手动清除：el.style.willChange = 'auto' - 避免
fixed和overflow: scroll在同一 DOM 路径上共存；如必须，给 fixed 父容器加transform: none !important强制解除合成 - 在 Java 层对 WebView 实例做兜底：过渡动画前临时关闭硬件加速：
webView.setLayerType(View.LAYER_TYPE_SOFTWARE, null)，动画结束后再切回LAYER_TYPE_HARDWARE - 启用离屏预光栅化（Android 5.0+）：
webSettings.setOffscreenPreRaster(true)，减少滚动丢帧
Native View 与 HTML fixed 层级完全不互通
这是最容易被忽略的跨上下文陷阱：iOS 原生侧用 addSubview: 叠加一个广告 Banner 到 WKWebView 上方，而 H5 页面里写了 z-index: 99999 的遮罩层，结果 Banner 一定盖在上面——因为 Native UIView 和 Web 渲染不在同一个合成树里，z-index 对原生层完全无效。
实操建议：
- 原生层叠加 UI（如悬浮按钮、横幅）必须通过
WKWebView的scrollView.addSubview:方式添加，确保同属 WebKit 渲染栈 - 若必须用 window-level view（如全局 toast），则 H5 侧需主动监听
resize或scroll事件，动态调整 fixed 元素的top值避开遮挡区 - 禁止在 JS 中依赖
getComputedStyle(el).zIndex判断层级关系——它只反映 CSS 层，不包含 Native 层
真正难调的从来不是样式本身，而是你写的 transform 和 z-index 在不同平台底层渲染路径中触发了完全不同的合成行为。别迷信“加个 translateZ(0) 就能加速”，先看它有没有把 fixed 元素锁进错误的 stacking context。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
