层重叠检测是识别非必要合成层叠加的分析策略，需用DevTools Layers面板定位冗余图层，通过约束will-change、使用contain、合并动画目标、JS回收图层等手段优化，并以Layers和Performance面板验证内存与主线程改善效果。
层重叠检测本身不是浏览器内置功能，但它是一种可落地的分析策略，用于识别因高频复合变换（如连续 transform 动画、滚动中反复触发 will-change）引发的合成层堆积与内存峰值波动。关键不在于“检测重叠”，而在于“识别非必要图层叠加”并阻断其生成链路。
用Layers面板定位重叠图层的实际路径
Chrome DevTools 的 Layers 面板是唯一能直观呈现图层空间关系的工具：
- 打开 DevTools → More Tools → Layers（或 Cmd+Shift+P 输入 “Show Layers”）
- 执行高频交互（如快速滚动、鼠标悬停动画），观察图层树中是否出现大量尺寸相同、Z 轴位置接近、且都带 “3D” 或 “transform” 标签的蓝色条目
- 点击任一图层，页面会高亮对应 DOM 元素；若多个相邻元素（如列表项、卡片容器、文字块）同时被高亮，说明它们被各自提升为独立合成层，形成视觉上重叠、逻辑上冗余的“图层堆叠”
- 特别注意父容器已设 transform 或 will-change 时，其子元素即使无样式变动，也可能因隐式分层规则被强制升层——这就是重叠的典型源头
从 CSS 层级结构入手切断重叠生成
高频变换常源于设计模式与实现方式错配，需在样式层做精准约束：
- 禁用全局或批量 will-change：避免 * { will-change: transform } 或 .list > * { will-change: transform }，改为仅对当前正执行动画的单个元素动态添加（例如 JS 中 el.style.willChange = 'transform'），并在 animationend 后立即设为 auto
- 用 contain: layout paint 替代“保险式”升层：对滚动区域（如 .scroll-container）设置该属性，可阻止内部变换影响外部布局计算，大幅减少连带升层，尤其适用于虚拟滚动场景
- 合并动画目标：若多个子元素（如图标+文字+边框）同步位移，不要分别加 transform，而是将它们包裹进一个共同父容器，只对该容器做变换，让浏览器复用同一合成层
- 慎用 perspective + rotateX/Y 组合：这类嵌套 3D 变换极易触发多层叠加，优先改用纯 2D 位移（translateX/translateY）或 opacity 动画，现代浏览器对其合成优化已足够成熟
用 JS 主动回收与防抖图层生命周期
浏览器不会自动清理已创建但不再活跃的合成层，需人工干预其生命周期：
- 对 hover 触发的变换（如 .card:hover { transform: translate3d(0,0,0) }），改用 pointerenter/pointerleave 事件监听，在 leave 后延迟 100ms 移除 transform 并重置 will-change，防止频繁进出导致图层反复创建
- 在滚动监听中加入 requestIdleCallback 或节流（throttle），避免每帧都触发布局重排或样式重算；对 scroll 事件中动态更新的元素，确保只在可视区域内激活变换，视区外元素还原为静态状态
- 长列表使用虚拟滚动时，卸载的 item 必须从 DOM 中完全 remove()，而非仅设 display: none 或 visibility: hidden——后者仍保留在渲染树中，其合成层可能持续驻留 GPU 内存
验证是否真正规避了内存峰值波动
优化后必须回归 Layers 和 Performance 面板交叉验证：
- Layers 面板中图层数量应显著下降（例如从 60+ 降至稳定在 4–6 层），且单层尺寸合理（避免全屏图层覆盖多个小元素）
- Performance 面板开启 Memory 轨道，录制高频操作全过程，观察内存曲线是否由“阶梯式上升”转为“小幅波动后回落”，峰值高度降低 30% 以上
- 对比优化前后主线程 Long Tasks 数量，若红条明显减少，说明图层管理改善也缓解了合成器线程压力，间接提升了主线程响应能力
