-webkit-overflow-scrolling: touch已基本弃用，因iOS 13+彻底移除支持，且会引发图层泄漏、事件干扰等问题；现代项目应优先使用标准overflow+明确高度（如height/max-height）配合硬件加速优化。
为什么-webkit-overflow-scrolling: touch现在基本不用了
这个属性曾是 iOS Safari 5.0–12.x 时代解决 scroll-view 或自定义滚动容器卡顿的“救命稻草”，但它本质是启用 WebKit 的原生惯性滚动引擎。问题在于：它只在旧版 Safari 有效，iOS 13+ 已彻底移除支持；启用后会强制创建独立图层，但无法控制生命周期，容易导致内存泄漏；更关键的是，它会干扰 touchmove 事件流，让下拉刷新、手势识别等逻辑失效。
overflow: auto 容器必须配 height 或 max-height
这是移动端自定义滚动卡顿最常被忽略的硬性前提。没有明确高度，浏览器无法计算滚动范围，会退化为“重排驱动滚动”，主线程反复计算 layout，直接掉帧。
- 错误写法：
<div class="list">...</div>+.list { overflow-y: auto; }（无高度） - 正确写法之一（推荐）：
.list { height: 100vh; overflow-y: auto; -webkit-overflow-scrolling: touch; }（仅兼容旧 iOS，现代项目可删最后一行） - 更健壮写法（Flex 布局）：
.container { display: flex; flex-direction: column; height: 100vh; } .list { flex: 1; overflow-y: auto; }
滚动区域里慎用 box-shadow、border-radius 和透明度动画
这些属性在滚动时会触发全量重绘（paint），尤其在中低端 Android 上，每帧耗时飙升。iOS 对阴影和圆角的合成优化较好，但叠加多层后仍会降帧。
- 替代
box-shadow：用伪元素 + 半透色背景模拟，或改用outline（不参与重排重绘） - 避免在滚动项上做
opacity动画：改用transform: translateZ(0)触发硬件加速，再配合will-change: transform（仅限真正位移的元素） -
border-radius超过4px且配合背景渐变时，建议用 SVG 替代或裁剪为固定尺寸图片
真机调试时优先看 Paint 和 Layout 耗时，不是 JS 执行时间
很多卡顿根本不在 JS 层——Chrome DevTools Performance 面板里，如果一帧中 Paint 占比超 60%，或者 Layout 频繁出现，说明 CSS 渲染链路已成瓶颈。这时候加 will-change 或改 transform 只是补救，根源往往在：
立即学习“前端免费学习笔记（深入）”；
- 列表项内图片没设
width/height，导致每次滚动都触发回流 - 用了
position: absolute且 left/top 依赖 JS 计算（如跟随滚动定位），应改用transform: translateY() -
scroll事件监听里调用了getBoundingClientRect()或修改了样式 —— 这类操作必须节流 +requestIdleCallback包裹
真正影响滚动流畅度的，从来不是某一行 CSS，而是整个渲染流水线是否被某个低效样式或未收敛的图层拖垮。尤其是 will-change，加错对象、不清理、嵌套使用，比不加还危险。
