CSS移动端滚动条样式美化：-webkit-scrollbar伪元素

简单直接的回答是：不能。绝大多数的移动端浏览器——包括 iOS 上的 Safari，以及 Android Chrome 从 v117 版本开始——都已经移除对 ::-webkit-scrollbar 的支持。这背后不是兼容性的小问题，而是一种主动的设计决策：在触屏场景下，滚动条本就不该出现去干扰用户的手指滑动操作。你就算写上一大堆 ::-webkit-scrollbar-track 和 ::-webkit-scrollbar-thumb 的样式规则，在 iPhone 上也是白搭——连最基础的 display: none 都不起作用。换句话说，这个伪元素在移动端早已是“有名无实”。

别费心思去给 ::-webkit-scrollbar 加什么媒体查询或是 UA 判断了，它在真机上的表现就是：完全不生效。

如何隐藏移动端滚动条？两个伪方案 vs 两个真方案

先看那些看起来“像”能解决问题，实则不靠谱的做法：

• overflow: hidden 直接让容器不能滚动——内容卡住看不到，也操作不了，这是最粗暴的“禁用”。
• -webkit-overflow-scrolling: touch 是 iOS 旧版时代拿来优化滚动惯性的，跟滚动条长什么样一毛钱关系都没有。而且这个属性在 iOS 16 后已经废弃，不要再抱幻想了。

真正能在移动端把滚动条藏起来的做法，无非两条路：

• 给容器设置 overflow: scroll，再加上 scrollbar-width: none——这一招 Firefox 是认的。
• 或者，用 ::-webkit-scrollbar { display: none }——但记住，这只对部分老版本的 Android Chrome 有效，iOS 全部无效。

还有一种更“取巧”的方式：手动算好滚动条宽度（大概 12px 左右），用 padding-right 把它挤开，再通过 margin-right: -12px 把位置拉回来。再配合 overflow: overlay（不过这属性也已经进历史垃圾堆了）。绕了半天，最后的结果往往是——不如放弃隐藏，直接接受系统默认的滚动条。

在真实项目中，隐藏滚动条这个需求，并不值得花太多心思。绝大多数用户根本不在意滚动条是圆角还是直角、宽度几个像素，他们只关心一个事：页面能不能顺畅地往下滑。

如果非要自己控制滚动行为，有什么替代方案？

用 JavaScript 去模拟滚动容器，是另一条可行的路。像 simplebar、overlay-scrollbars 这类库，或者干脆手动控制 scrollTop 的值，都能做到。但代价也不小：

• 必须同时监听 touchstart 和 touchmove，不能只依赖 mousewheel 事件。
• 惯性效果（momentum）得自己手动模拟——iOS 的 WebKit 在触摸结束前不会触发 scroll 事件，得靠 requestAnimationFrame 加一个速度衰减算法来仿真。
• 原生滚动的流畅度和性能优势会被彻底破坏，尤其在长列表里，掉帧几乎是必然的。
• 如果容器内还有 position: fixed 的子元素，在自定义滚动中使用时很容易错位，得靠 transform: translateZ(0) 强制提升图层。

如果页面不复杂，overlay-scrollbars 是个可以接受的库——它会自动做降级：在桌面端浏览器的支持场景下用 ::-webkit-scrollbar 伪元素来美化，而在移动端则退回到轻量级的 JS 控制。

但总的来说，让滚动条保持系统默认，去拥抱它原本的样子，才是最稳妥的选择——它不抢焦点，不引起卡顿，也不让你的 bundle 体积多出一份。

为什么开发者总想改滚动条？

说到底，还是 PC 端能随便用伪元素改样式，让大家习惯性地觉得“移动端应该也能”。但移动端的交互逻辑完全是另一回事：没有鼠标悬停、没有精确的坐标点击，滚动本身就是用户最核心的交互手势。任何一个“美化”后的滚动条，其实往往是把它从一个系统级的无障碍组件，替换成一个更慢、更难用、更不可靠的仿制品。

真正值得花时间的地方，不是滚动条长什么样——而是容器有没有明确的 height 或 max-height，内容会不会意外撑开，滚动区域的边界是否清晰。这些，才是决定用户体验好坏的关键。