移动端Chrome overflow-x滑动更“硬”是因为其默认不启用惯性滚动上下文，需显式设置touch-action: pan-x、避免祖先节点touch-action: none、scroll监听器必须加{ passive: true }、滚动容器高度需明确固定。
为什么移动端Chrome的overflow-x滑动比iOS Safari更“硬”
不是CSS写错了，是Chrome（尤其是Android WebView）默认不启用惯性滚动上下文，overflow-x: auto容器松手即停，缺乏iOS那种自然回弹和阻尼感。这跟WebKit旧引擎无关，而是Blink对滚动链的处理策略不同：它更倾向“精确控制”，但牺牲了手感。
必须加touch-action: pan-x，且不能被祖先拦截
很多项目在body或wrapper上写了touch-action: none来禁用双指缩放或长按菜单，结果意外阻断了所有子级的横向滚动能力——哪怕你只在卡片容器里设了touch-action: pan-x，也会被父层继承覆盖。
实操建议：
- 检查
document.documentElement和body是否被JS动态注入touch-action: none - 给滚动容器显式声明
touch-action: pan-x，并确保其所有祖先节点未设touch-action: none或touch-action: manipulation - 避免在滚动容器上绑定
touchstart却不调用e.preventDefault()，否则Chrome会降级为非被动滚动模式
scroll事件监听器没加{ passive: true }就是卡顿主因
Chrome 63+ 强制要求滚动类事件监听器声明{ passive: true }，否则会同步阻塞滚动线程，帧率直接从60fps掉到20fps以下。这不是可选项，是强制性能门槛。
错误写法：el.addEventListener('scroll', handler)
正确写法：el.addEventListener('scroll', handler, { passive: true })
注意：如果确实需要阻止默认行为（比如拖拽排序），改用touchstart + e.preventDefault()，不要在scroll里做判断。
滚动容器高度不确定会导致阻尼失效
Chrome对overflow-x容器的惯性计算依赖明确的“可滚动范围”。若容器高度为auto、靠flex内容撑开、或用了100vh（地址栏展开时塌缩），Chrome就无法预估滚动边界，从而关闭原生阻尼逻辑。
实操建议：
- 给滚动容器设固定
height或min-height（如min-height: 44px） - 如果是Flex子项，父容器需加
min-height: 0防止高度塌陷 - 避免用
vh单位定义滚动区域高度，改用px或rem
真正难搞的点不在样式本身，而在滚动容器的“可预测性”——Chrome需要确切知道它能滚多远，才肯给它配阻尼。一旦这个信息模糊，它就退回最保守的硬停止模式。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
