旧安卓机css动画黑屏主因是gpu图层泄漏oom，需删除will-change、慎用backface-visibility、统一animation-fill-mode与关键帧、限制infinite次数。
旧安卓机（Android 4.4–6.0）上 CSS animation 黑屏，几乎可以确定是 GPU 图层泄漏导致的 OOM，不是动画写错了，也不是没加前缀。
Android 4.4–6.0 WebView 中 will-change 是定时炸弹
这些版本的 WebView 合成器存在内存管理缺陷：will-change: transform 一旦设上，动画期间持续分配 GPU 图层却从不回收。几秒后内存耗尽，直接触发 OOM，页面黑屏或白屏，且无控制台报错。
- 全局搜索项目中所有
will-change声明，优先全部删除；尤其禁止写在 CSS 文件里长期生效，例如.slide { will-change: transform; } - 如确需临时启用（实测卡顿且确认是合成层缺失），必须用 JS 在动画前一帧动态注入：
el.style.willChange = 'transform' - 必须在
animationend或transitionend回调中立刻清理：el.style.removeProperty('will-change') - 绝对不要和
backface-visibility: hidden同时使用——两者叠加会加剧图层隔离，导致position: absolute元素直接消失
backface-visibility: hidden 在旧安卓上可能引发黑块
在 Android 4.4–5.1 系统 WebView 中，backface-visibility: hidden 会强制创建独立合成层，并切断该层与视口定位上下文的关联。结果就是 position: fixed 或 absolute 元素被跳过渲染，DevTools 里高亮但 Computed 显示 display: none，截图呈黑或透明区域。
- 快速定位：在 Styles 面板中搜索
backface-visibility，向上逐级检查所有父容器（哪怕只是.wrapper上写了这一行） - 临时禁用验证：手动设为
backface-visibility: visible或直接删掉，刷新看黑块是否消失 - 替代方案优先选
will-change: transform单独触发合成，或改用contain: layout paint（Chrome 90+ 支持良好） - 完全去掉该声明，靠
opacity+transform组合本身就能触发 GPU 加速，无需额外干预
animation-fill-mode 和关键帧不一致导致逻辑跳变
很多“黑”其实是视觉错觉：动画循环时突然回跳到初始状态、缩放结束时“抽搐一下”，本质是样式逻辑冲突，而非渲染崩溃。
- 动画循环跳变？补上
animation-fill-mode: both或forwards，但注意：若需后台切回重播，必须设为none - 缩放/位移动画结束抽搐？检查
@keyframes最后一帧的transform值是否与元素默认值**完全一致**（空格、单位、顺序都不能差） - 用
steps()时闪动？说明步进数与实际帧率不匹配，优先改用linear，或手动调animation-duration -
animation-iteration-count: infinite在旧安卓上极易触发图层泄漏，务必限制次数，例如30
真正麻烦的不是某一行样式写错了，而是多个合成层控制指令（will-change、backface-visibility、transform、overflow: hidden）在 DOM 树不同层级上叠加作用，最终让某个 fixed 导航栏或轮播图容器彻底脱离渲染管线——这时候得一层层查祖先节点，而不是盯着目标元素调 background-color。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
