GPU图层过多导致内存暴涨，因每个合成层预分配约4MB显存，且与CPU双向映射；will-change或transform等触发被动升层，批量使用易瞬占大量显存，Layer Borders可实时验证问题图层。
GPU图层过多直接导致内存暴涨，核心原因是每个合成层都占用独立的GPU纹理内存（通常约4MB），且CPU与GPU之间存在双向内存映射。
每个will-change或transform: translateZ(0)都在悄悄分配显存
浏览器对满足条件的元素（如含transform、opacity、filter等属性的元素）会创建独立合成层，并为该层分配一块GPU纹理内存。这不是“按需使用”，而是“一经提升即预分配”。哪怕元素只是短暂hover触发will-change: transform，也会立即申请一块连续显存。
- 常见错误现象：
div:hover { will-change: transform; }在列表项上批量使用，视口内20个item同时匹配 → 瞬间多出20×4MB ≈ 80MB GPU内存 - Android WebView中更危险：旧纹理常不释放，叠加
canvas或iframe子节点，极易触发OOM - 不要依赖
chrome://gpu里“Compositing: Enabled”就认为安全——它只表示能力开启，不反映当前图层数量
Layer Borders是唯一能实时验证图层爆炸的工具
DevTools的Rendering面板中勾选Layer Borders后，每块彩色边框代表一个独立合成层。这不是示意，而是真实内存分配单元。你看到的边框越多，进程总内存（非JS堆）越可能失控。
- 关键操作：切换不同视口宽度，观察@media断点切换时是否突然多出大片边框——这说明媒体查询激活了冗余
transform或will-change - 注意外层容器影响：给
body加will-change: transform，可能让所有子元素“被动升层”，尤其当子元素本身有position: absolute时 - Chrome 128+已支持在Layers面板中点击图层查看其内存占用（单位KB），比肉眼数边框更准
Canvas和CSS图层共用同一套GPU内存池
Canvas硬件加速开启后，其纹理内存与CSS合成层共享同一GPU内存池。一个10000×2000的<canvas>本身就要占约80MB显存；若页面再有10个will-change元素，很容易突破移动端GPU内存上限（通常256–512MB），触发强制降级或白屏。
立即学习“前端免费学习笔记（深入）”；
- 典型陷阱：高DPR设备上写
canvas.width = 3840; canvas.height = 2160;（4K尺寸），实际分配显存≈3840×2160×4字节 ≈ 33MB，远超所需 - 修复方向：用
ctx.scale(dpr, dpr)替代放大width/height，保持canvas物理尺寸贴近视口（如800×600），显存可控 - 离屏Canvas（
OffscreenCanvas）也不能乱用：transfer到Worker后若未及时close()，GPU纹理仍驻留
图层不是越多越好，而是越精准越好。真正需要GPU加速的，往往只是动效区域本身，而不是它的父容器、兄弟节点甚至整个body。一旦发现内存飙升，先关掉Layer Borders，数清楚哪几个边框是“不该存在”的——那才是问题根因。
