给列表项加 will-change: transform 反而更卡，因强制为每个项创建独立合成层导致 gpu 内存暴涨、图层数飙升；真正治本方案是虚拟滚动+contain 隔离渲染边界。
为什么给列表项加 will-change: transform 反而更卡
这不是配置没生效，而是浏览器被你“提示”错了。Chrome 98+ 已默认对 transform 和 opacity 启用硬件加速，will-change 在此时不是开关，而是高风险指令：它强制每个匹配元素创建独立合成层。列表有 300 个 .item，你就等于主动建了 300 个图层——DevTools 的 Layers 面板里图层数飙升、GPU 内存暴涨，尤其在 Android WebView 或 iOS Safari 上，极易触发内存回收式卡顿。更糟的是，如果动画混用了 left 或父容器有 overflow: hidden，will-change 根本不走合成路径，纯属白加。
真正拖慢渲染的从来不是“动画”，而是“全量渲染”
大数据量列表卡顿的根源，是浏览器每帧都要 layout + paint 几百个 DOM 节点。哪怕你只动 transform，layout 阶段仍要为每个子项测量尺寸、计算 flex 分配、处理 flex-grow 冲突——will-change 对这个过程零优化。此时任何图层提示都治标不治本。
- 优先上虚拟滚动：只渲染视口内 ±2 屏的项（比如 20 个），其余用固定高度的占位
<div> 维持滚动高度，<code>flex容器照用，但子项数量从 500 直降到 20 - 禁用动态
calc()：如flex-basis: calc(33.33% - 20px)会在每轮 layout 中重复求值，换成 CSS 变量（--item-width: 320px）或固定值 - 扁平化嵌套：避免
flex > div > flex > .item这种结构，多层 flex 容器会让 WebKit 放弃布局缓存，每次更新都重算整棵树 - 该元素确实在做纯
transform或纯opacity动画（@keyframes或transition中不能出现top、width、background-color等触发布局或重绘的属性） - 动画帧率已实测低于 55fps（用 Chrome DevTools > Rendering > FPS Meter 验证，非肉眼判断）
- 该元素是动画的直接载体，比如某个悬停放大的按钮，而不是整个列表容器或通用类选择器
哪些场景下 will-change 才真有用
仅当同时满足以下全部条件时，才考虑给**单个目标元素**加 will-change: transform 或 will-change: opacity：
且必须 JS 动态控制：element.style.willChange = 'transform' 放在动画开始前一帧；结束后用双层 requestAnimationFrame 清理，确保绘制完成再销毁图层，避免闪屏。
比 will-change 更安全的替代方案
对确实需要局部动画的项（如 hover 卡片），直接写 transform: translateZ(0) 触发硬件加速，无需 JS 生命周期管理，也无图层爆炸风险。对 Grid 或 Flex 容器中的子项，加 contain: layout style paint 明确隔离渲染边界——它告诉浏览器“这个元素内部怎么变，都不会影响外面”，能大幅减少重排扩散范围。注意：contain 只对直接子项有效，加在容器本身或正在做 transform 动画的元素上反而可能破坏连贯性。
