真正起效的组合是 touch-action 明确手势意图并配合动态 will-change：滚动开始时给子元素设 will-change='transform'，结束 100ms 后移除；同时避开 overflow+border-radius、opacity、filter 等抑制合成的 CSS 陷阱。
对滚动容器本身加 transform: translateZ(0) 或 will-change: transform 不仅无效，反而会让低端 Android 和旧 iOS 更卡——真正该动的是「正在被 touchmove 驱动的可滚动内容区域」，且必须配合 touch-action 才能释放性能。
为什么 scroll 容器上加 translateZ(0) 会更卡
浏览器看到 transform: translateZ(0) 就会为该元素创建独立合成层，但原生滚动（scrollTop / scrollTo）并不走 transform 渲染管线。结果是：滚动时 CPU 仍在计算 layout + paint，GPU 图层却空转占显存，尤其在 Android WebView 或 iOS Safari 14 以下机型中，内存压力直接导致掉帧甚至白屏。
- 错误写法：
.scroll-wrapper { transform: translateZ(0); overflow-y: auto; } - 现象：手指一松就停，惯性消失；快速滑动时出现“顿挫感”；DevTools 的 Layer Borders 显示大片绿色但 FPS 掉到 30 以下
- 根本原因：硬件加速只对 CSS 动画/transform 变化生效，对原生滚动 API 无优化作用
真正起效的组合：touch-action + 动态 will-change
移动端滚动卡顿的主因不是“没加速”，而是浏览器默认要等 300ms 判定是否双击，导致 touchmove 延迟触发。必须用 touch-action 明确手势意图，再只对当前位移中的子元素临时升层。
- 给可滚动容器设
touch-action: pan-y（纵向）或pan-x（横向），禁止none除非你完全接管手势 - 滚动开始时（
touchstart或首个touchmove），给实际位移的子元素（如.list-content）加style.willChange = 'transform' - 滚动结束 100ms 后（监听
touchend+setTimeout），立刻执行el.style.removeProperty('will-change') - 若容器内有可点击区域（如卡片），子元素需单独加
touch-action: manipulation，否则点击失效
必须避开的渲染陷阱
即使加了 touch-action 和动态 will-change，以下 CSS 组合仍会强制回退到软件渲染，让所有优化归零：
立即学习“前端免费学习笔记（深入）”；
-
overflow: hidden+border-radius同时存在：iOS Safari 会禁用 GPU 合成，改用 CPU 绘制圆角遮罩 - 父容器设置了
opacity: 0.99或filter: blur(1px)：会抑制子元素提层，translateZ(0)白加 - 滚动区域用了
scroll-behavior: smooth：与 JS 手动scrollTo冲突，导致合成层反复切换，视觉撕裂 - 使用
100vh设高：iOS 地址栏收起时视口变化，滚动容器高度塌缩，touch-action失效；应改用100dvh或 JS fallback
验证是否真生效的三步检查法
光写属性不等于 GPU 在干活。打开 Chrome DevTools → Rendering → 勾选 Layer Borders、FPS meter、Paint flashing：
- 有绿色边框 + FPS 稳定在 55–60 → 成功升层且无重绘泄漏
- 有绿框但 FPS 波动大 + Paint flashing 在滚动区域外大面积闪烁 → 动画属性不纯（比如同时改了
height或background-color） - 没绿框 → 要么被父容器压制（检查
opacity/filter），要么浏览器不支持（Android 4.4 以下）
复杂点在于：同一套 CSS，在 iOS Safari 和 Android Chrome 中的合成行为可能完全不同；而用户是否正用着 WebView、是否开了“减少动画”系统偏好，都会让 will-change 的效果打折扣。别指望一个属性解决所有问题，得按设备和上下文分层控制。
