CSS 层级故障复盘，别只写一句“加硬件加速”

CSS 层级故障复盘，别只写一句“加硬件加速”

复杂仪表盘、弹窗和动画集中在一个页面时，掉帧常被归咎于“CSS 太多”。这个说法没有帮助。浏览器如何分层、何时栅格化、哪个动画占用主线程，都要回到性能记录和实际设备上看。给每个元素加 transform、will-change 或极大的 z-index，反而可能让问题更难收拾。

排查的目标不是消灭所有合成层，而是让层级关系可预测，让高成本的动画只在真正需要时出现，并且能解释一次性能回退来自哪里。

先看记录，再解释属性

浏览器开发者工具中的性能、渲染和图层视图可以帮助观察滚动、打开弹窗、切换 tab 等具体操作。记录时关注帧的时间线、绘制区域、合成和栅格化工作，以及页面上哪些节点在持续变化。不同浏览器和设备的实现会有差异，不能只因一个 CSS 属性就断言它必然创建或移除某个图层。

例如 will-change 是提示，不是性能开关。长期给大量元素设置它，可能占用更多图形资源；在动画即将发生时短暂使用，才更符合它的用途。transform 常适合做位置和缩放动画，但也不是所有场景都比修改其他属性更快，仍要看实际绘制范围和内容。

同样，z-index 很大不代表“更安全”。它只在相应堆叠上下文中比较。父元素的定位、opacity、transform、isolation 等都可能建立新的上下文，导致弹窗看起来被意外遮住。不断把数值改得更大，只会让规则失去可读性。

建立有限的层级体系

应用可以约定少量语义层级，例如普通内容、吸顶区域、下拉层、模态框、通知层。用 CSS 变量或共享常量表达这些层级，组件不直接写随意的数值。这样出现遮挡时，讨论的是“这个组件是否应该属于模态层”，而不是“把它改成多少”。

局部容器有时适合建立独立的堆叠上下文，以防内部装饰元素影响外部内容。但它不是万能隔离方案。使用 isolation 或其他属性前，要确认弹窗、tooltip 等是否需要越过该容器；很多浮层更适合挂在应用统一的 portal 根节点，由一个明确的层级管理器控制。

动画也要有边界。只对当前交互元素动画，避免同时让整张表格或大面积背景发生昂贵的效果。对低性能设备或用户偏好减少动态效果的情况，提供较轻的路径。视觉效果是产品的一部分，不应以输入延迟为代价。

修复后按交互路径复测

选择能稳定触发问题的步骤：打开多层弹窗、快速滚动、切换大图表、连续 hover。分别在目标设备和浏览器上录制，比较修复前后的长任务、绘制区域和交互响应。只在开发机上流畅，不代表真实设备也没有问题。

复盘记录应包含可重现步骤、受影响版本、关键 DOM 和样式关系、采样结果、采取的修改以及回归检查。不要把“开启 GPU 加速”写成结论；要说明哪个元素为什么需要调整，修改后哪个指标或现象发生了变化。这样后来新增组件时，团队才能知道哪些约束不能随意突破。

CSS 性能问题并不神秘，难点在于它总是和页面结构、资源大小和交互方式混在一起。让层级有规则，让动画有范围，让每次判断有记录，排查就不必依赖猜测。