给长列表项加 will-change: transform 反而更卡，因触发合成层爆炸致 GPU 内存失控；应仅对滚动容器设 will-change: transform 并配合真实 transform 变化，优先采用虚拟滚动治本。
直接给长列表的每一项加 will-change: transform 不仅没用，反而会让中低端安卓机掉帧到 20fps 以下——这不是配置问题，是合成层爆炸导致的 GPU 内存和上下文切换失控。
为什么给列表项加 will-change 反而更卡
浏览器对每个带 will-change: transform 的元素都会尝试创建独立合成层。一屏显示 10 个 .item，滚动过程中视口内常驻 20+ 个，等于瞬间塞给 GPU 20 多个图层。现代移动端 GPU 显存有限，尤其 Android 旧机型（如 Chrome 85–95），极易触发纹理上传阻塞或合成器抖动。
-
will-change不是“加速开关”，而是“请提前准备图层”的提示；浏览器是否真建层、建多大、何时回收，全由实现决定 - 列表项通常只做位置偏移（
transform: translateY()），但若父容器有overflow: hidden+border-radius，会强制回退软件渲染，will-change完全失效 - Vue/React 中若
.item是未 memo 化的函数组件，每次重渲染都可能触发样式重计算，will-change只是放大开销
真正该设 will-change 的地方只有一个
只对实际承载滚动位移的容器设，比如 .list-container 或 .scroll-content，且必须配合真实 transform 变化才生效。
- 写法必须是：
will-change: transform+ 对应元素有transform: translateZ(0)或动态transform: translateY(...) - 禁用
will-change: scroll-position：它在多数浏览器中被忽略，iOS Safari 完全不支持，且对原生滚动无加速作用 - 不要写在 CSS 文件顶层（如
.item { will-change: transform; }），这等于让所有列表项永久占着 GPU 内存 - 用 Chrome DevTools → Layers 面板确认：图层数应稳定在 3～5 层，超过 8 层就要立刻排查
比 will-change 更关键的三件事
90% 的长列表卡顿根源不在渲染层，而在主线程被拖住或布局反复重算。
立即学习“前端免费学习笔记（深入）”；
- 滚动监听必须加
{ passive: true }：container.addEventListener('scroll', handler, { passive: true })，否则 iOS Safari 可能禁用惯性滚动 - 绝对禁止在
scroll回调里读取scrollTop、getBoundingClientRect()或写element.style.xxx——这会强制同步回流（layout thrashing） - 图片必须设宽高 +
loading="lazy"，否则每张图加载都触发重排；优先用IntersectionObserver替代 scroll 监听做懒加载
真正治本的方案不是 will-change，是虚拟滚动
will-change 是修水管，虚拟滚动是换管道。它把 DOM 节点数从几千压到视口内 10～20 个，其余用 padding-top/bottom 占位，滚动性能提升来自 DOM 规模下降，而非 GPU 加速。
- 别手写：React 用
react-window，Vue 用vue-virtual-scroller，它们已处理 iOS 滚动边界、键盘聚焦、可访问性等坑 - 服务端若返回分页游标（cursor），就别传
total count—— 虚拟滚动不需要知道总条数 - 禁用
position: sticky或靠transform: translateY()模拟滚动位移，这些仍需浏览器持续计算每个元素位置，无法规避重排
最常被忽略的一点：will-change 必须和真实的 transform 变化绑定才有意义。如果只是静态设了属性却没后续动画或位移，浏览器大概率忽略它，或者建了层又白占内存——你得先确认滚动确实是靠 transform 驱动的，而不是 scrollTop 或 CSS scroll-behavior。
