在移动端使用 CSS 隐藏 Safari 滚动条并保留滚动能力，其实并没有想象中那么稳定。关键原因在于 iOS Safari，尤其是 iOS 16 之前的版本，通常会直接忽略 ::-webkit-scrollbar，同时也不支持 scrollbar-width:none。而在 iOS 和 Android 上的 Chrome、Edge 等浏览器中，更稳妥的做法是结合 width:0 与 opacity:0 一起使用，这样既能实现滚动条隐藏效果，也能尽量保证页面正常滚动。至于 Firefox for Android，处理方式相对直接，使用 scrollbar-width:none 通常就可以达到目的。
移动端 Safari 隐藏滚动条本身就不稳定
iOS Safari（特别是 iOS 16 之前）基本会忽略 ::-webkit-scrollbar，同时也不支持 scrollbar-width: none。很多开发者以为自己“成功隐藏了滚动条”，其实更多只是因为 Safari 默认就不明显显示滚动条，但用户依然可以通过触控板、键盘方向键或辅助功能继续滚动页面。若强行使用相关伪元素，反而可能带来兼容性问题，例如 Safari 15 的部分版本中，设置 ::-webkit-scrollbar { display: none } 还可能导致拖拽滚动失效。
Chrome / Edge on iOS 和 Android 更适合使用 width + opacity 组合隐藏滚动条
在移动端 Chromium 系浏览器中，例如 iOS 上的 Chrome，以及 Android 平台的大部分浏览器，直接给 ::-webkit-scrollbar 设置 display: none 并不是可靠方案。某些旧版本浏览器可能不只是把滚动条隐藏，还会把滚动能力一并禁用。更安全、更实用的思路，是让滚动条依旧存在，但在视觉上不可见，从而实现“隐藏滚动条但保留滚动”的效果。
- 给
::-webkit-scrollbar设置width: 0或width: 4px（保留最小可交互区域，降低触控异常风险） - 将
::-webkit-scrollbar-track与::-webkit-scrollbar-thumb同时设为background: transparent或opacity: 0 - 滚动容器必须明确设置
overflow-y: auto或scroll，并确保内容确实发生溢出 - 不要只写
::-webkit-scrollbar而忽略 track/thumb，否则某些 Android WebView 仍可能渲染出灰色滚动条残影
Firefox for Android 使用 scrollbar-width: none 更省事
Firefox 移动端（Gecko 内核）支持 scrollbar-width: none，而且整体表现较为稳定：可以实现视觉上隐藏滚动条，同时完整保留滚动功能，也支持惯性滚动和键盘导航。不过它只会对设置了 overflow: auto 或 scroll 的块级元素生效，不能简单写在 body 或 html 上就期待全局生效——必须明确应用到具体的滚动容器，例如 .content-scroll。
真正需要警惕的不是滚动条，而是页面布局偏移
隐藏移动端滚动条后，容器宽度有时会突然变大（因为原本被滚动条占用的空间消失），从而引发内容重排、文字换行异常等布局问题。尤其是在竖屏切横屏、输入法键盘弹出时，这类现象会更加明显：
- 可以通过
padding-right: 16px补偿常见滚动条宽度（但 iOS 并没有固定值，通常需要借助 JS 动态测量） - 相对更稳的思路不是一味追求隐藏，而是结合
overscroll-beha vior: contain控制回弹行为；至于overflow: overlay已被废弃，不建议继续使用 - 测试时一定要进行真机验证：模拟器往往无法完全还原真实滚动表现，Safari 开发者工具中的“Toggle Device Toolbar”也不一定能反映真实触控反馈
最容易被忽视的一点是：移动端滚动是否正常，往往还依赖 touch-action 与 pointer-events 的默认继承关系。一旦父级元素设置了 pointer-events: none 或 touch-action: pan-x，即使 CSS 已经完美实现隐藏滚动条，也依然无法挽救滚动失效的问题。
