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