-webkit-overflow-scrolling: touch 已废弃，iOS 8 起不推荐，iOS 13+ 完全失效；现代 WebKit 默认启用原生惯性滚动，添加反而可能引发卡顿、错位等问题，新项目应直接移除。
为什么 -webkit-overflow-scrolling: touch 现在基本不用了
它曾是 iOS Safari 解决局部滚动卡顿的“救命稻草”，但自 iOS 8 起就进入废弃状态，iOS 13+ 已彻底不生效；现代 WebKit（包括 Safari 16+）默认启用原生惯性滚动，强行加这句反而可能干扰滚动行为或触发意外重绘。
常见错误现象：-webkit-overflow-scrolling: touch 加了没效果、滚动变迟滞、下拉刷新失效、position: fixed 元素错位。
- 仅适用于 iOS 5–7 的老旧 WebView 场景，新项目请直接移除
- 若你还在维护一个老 Hybrid App 并卡在 iOS 9 以下，才需保留并配合
overflow: auto+height或max-height显式设定容器尺寸 - 它无法解决「JS 滚动监听阻塞主线程」这类根本问题，只是表面加速
真正影响移动端滚动流畅的关键 CSS 属性
滚动卡顿主因是合成层缺失或频繁重排重绘。重点不是加什么 hack，而是避免触发非合成操作。
-
will-change: scroll-position：对滚动容器提前提示浏览器“这个元素会滚动”，促使创建独立合成层；但不要滥用，只加在明确需要优化的容器上（如.scroll-container） -
transform: translateZ(0)或transform: translate3d(0, 0, 0)：强制 GPU 加速，适用于 iOS 12–15 中部分未自动合成的场景；注意它会创建新的 stacking context，可能影响z-index和遮罩逻辑 - 避免在滚动区域父级使用
filter、opacity 、<code>mask等触发全层重绘的属性 - 确保滚动容器有明确的
height或max-height，否则overflow: auto可能失效或导致布局抖动
滚动监听时 JS 带来的性能陷阱
CSS 本身不执行逻辑，但常和 scroll 事件绑定，一写错就拖垮帧率。
立即学习“前端免费学习笔记（深入）”；
- 别直接在
scroll回调里调用getBoundingClientRect()或读取offsetTop—— 这会强制同步回流 - 用
requestAnimationFrame节流：只在下一帧开始时读取位置，例如rafId = requestAnimationFrame(() => { /* 读取 scrollTop */ }) - 优先用
IntersectionObserver替代滚动监听做懒加载或吸顶判断；它不触发重排，且由浏览器异步调度 - 如果必须监听，用
passive: true选项：el.addEventListener('scroll', handler, { passive: true })，防止浏览器因等待 JS 执行而延迟滚动响应
调试滚动性能的实际路径
别猜，打开 Safari 开发者工具（macOS 上连真机）看真实瓶颈。
- 在「Timelines」面板勾选「Rendering Frames」和「Events」，滚动时观察是否频繁掉帧（红色标记）、是否有长任务阻塞
- 点击「Layers」面板，确认滚动容器是否已提升为独立图层（显示为带编号的矩形块）；若没有，检查是否漏了
will-change或被父级filter抑制 - 在「Elements」中选中滚动容器，右侧「Computed」标签页搜索
transform和will-change，确认值已生效 - 禁用所有 JS 监听器后仍卡顿？那大概率是 CSS 动画/渐变/阴影太重，或图片未压缩、未设置
decoding="async"
滚动流畅性不是靠某个 CSS 魔法开关，而是合成层控制 + 避免强制同步布局 + 合理的 JS 调度三者配合；-webkit-overflow-scrolling 是历史包袱，现在该把它从代码里删干净了。
