加 will-change: transform 到滚动容器会加剧 iOS Safari 卡顿，因其触发合成器过载；正确做法是仅对 touchmove 驱动且用 transform 位移的子元素动态启用并及时清理，优先使用 -webkit-overflow-scrolling: touch。
直接加 will-change: transform 到滚动容器上，不仅不能缓解卡顿，反而大概率让 iOS Safari 更卡——这不是配置没生效，而是触发了合成器过载。
为什么 will-change 在滑动场景下容易适得其反
will-change 的作用是提前通知浏览器“这个元素接下来要变”，好让它把该元素升到独立合成层。但前提是：变化确实高频、持续、且不牵扯布局计算。
而原生滚动（scrollTop 或 scrollTo）本身不走 transform，也不触发 will-change 所期待的合成路径；强行加，只会让浏览器白占 GPU 内存、增加图层管理开销。
常见错误现象包括：
- iOS Safari 滚动掉帧，尤其在快速拖拽或惯性滑动时
- 页面其他动画（如弹窗入场）同步卡顿
-
overflow: hidden+border-radius组合下，强制回退软件渲染，will-change完全失效
真正该加 will-change 的时机和对象
只对「正在被 touchmove 驱动、且用 transform 模拟位移」的元素动态启用，滑动结束立刻清理。
- 使用
requestAnimationFrame驱动transform: translateY()动画时，才需要will-change: transform - 必须在
touchstart时添加，touchend/touchcancel后 100ms 内移除 - 作用目标必须是实际位移的子元素（如
.list-content），不是父容器（如.list-wrapper）
element.addEventListener('touchstart', () => {
element.style.willChange = 'transform';
});
element.addEventListener('touchend', () => {
setTimeout(() => {
element.style.willChange = 'auto';
}, 100);
});
比 will-change 更关键的前置条件
will-change单独存在几乎无效。iOS 滚动手势卡顿的根因，往往卡在事件响应链上：
- 默认 300ms 双击判定会延迟
touchmove触发，必须用touch-action: pan-y显式声明滚动方向 -
touch-action不继承，子元素有可点击区域（如按钮、卡片）时，需单独设为touch-action: manipulation - 若同时用了
scroll-behavior: smooth和 JS 手动 scroll 控制，两者冲突会导致视觉撕裂，必须禁用前者
替代方案：优先用原生滚动 + -webkit-overflow-scrolling
纯 CSS 滚动无需 will-change，也别加。对可滚动容器设置：
.scrollable {
overflow-y: scroll;
-webkit-overflow-scrolling: touch;
height: 300px;
}
这行私有属性直接启用 iOS 原生滚动引擎，硬件加速由系统接管，比任何 JS + transform + will-change 组合都更稳。但它有副作用：z-index 层级错乱、输入框失焦、滚动位置丢失——这些才是你真该花时间处理的点，而不是反复调 will-change。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
