层重叠检测并非浏览器内置功能，实为对Layer borders、Paint flashing等渲染调试能力的误称；内存峰值主因是高频复合变换导致无效图层堆积与回收滞后，需通过Layer borders+Compositing Reasons定位升层源、Performance面板识别异常触发点、主动控制图层生命周期（如慎用translate3d/will-change、添加contain属性）来收敛图层数量并稳定GPU内存。
层重叠检测（Overlap Testing）本身不是浏览器内置的调试功能，也不直接用于规避内存峰值波动。当前 Chrome DevTools、Firefox 或 Safari 均无名为“Overlap Testing”的独立面板或开关。你遇到的可能是对 Layer borders（图层边框高亮）、Paint flashing（重绘闪烁） 或 Compositing reason 标注 的误称，或是某些定制化性能监控脚本中的内部命名。
真正影响内存峰值的核心机制是：高频复合变换（如连续触发 translate3d、rotateY、scaleZ）会反复强制元素升层 → 创建新合成层 → 占用 GPU 显存 → 层未及时回收 → 内存持续累积 → 触发 GC 压力或 GPU 进程崩溃。所谓“重叠”，只是视觉表象；本质是无效图层堆积 + 回收滞后。
要稳定内存、规避峰值波动，需从三层入手：识别、归因、收敛。
用 Layer borders + Compositing Reasons 定位“伪重叠”升层源
打开 DevTools → ⋯ → More Tools → Rendering → 勾选 Layer borders 和 Paint flashing：
• Layer borders 会用绿色边框标出所有已提升的合成层（含因 transform、opacity、filter 等触发的）；
• 配合鼠标悬停，可快速看到每个边框旁标注的 “Composited due to: will-change” 或 “transform” 等原因；
• 若发现大量相邻元素（如列表项、轮播卡片）同时被绿色框包围，且 hover/scroll 时边框频繁闪现/新增，说明存在“非必要高频升层”。
识别高频变换的真实触发点
很多“重叠感”来自 JS 动画库或手势逻辑中未节流的 transform 更新：
• 使用 Performance 面板录制（勾选 Paint & Layout），回放时观察 “Composite Layers” 事件是否密集出现（每帧多次）；
• 在 Bottom-up 标签页 中筛选关键词：updateLayerTree、commitLayerChanges、syncCompositorState —— 若这些函数调用频次 >30 次/秒，即为异常；
• 检查是否在 requestAnimationFrame 或 scroll 回调中直接写 el.style.transform = 'translate3d(...)' + i，而未做 diff 或缓存判断。
收敛图层数量，切断内存增长链
不靠“检测重叠”，而靠主动控制图层生命周期：
• 对仅需位移动画的元素，改用 transform: translateX(0) 替代 translate3d(0,0,0) —— 同样触发合成，但避免 Z 轴隐式创建新层；
• will-change 必须严格按需设置：动画开始前 JS 添加，animationend 或 transitionend 后立即清除（el.style.willChange = 'auto'）；
• 为滚动容器添加 contain: layout paint，阻断内部 transform 向外扩散升层；
• 避免父容器设 perspective + 子元素设 rotateY 的嵌套组合 —— 浏览器会为每个子元素单独创建 3D 上下文，图层数量呈 N² 级增长。
验证是否真正收敛
优化后必须交叉验证三项指标：
• Layers 面板中图层数量稳定（例如从动态 60+ 降至恒定 4–6 层）；
• Chrome 任务管理器（Shift+Esc）中 “GPU Process” 内存曲线不再阶梯上升，波动幅度 ≤5MB；
• Performance 录制里 “Memory” 轨迹中 GPU Memory（若启用 chrome://flags/#enable-gpu-memory-buffer-video-frames）趋于平缓，无持续爬升趋势。
