移动端::-webkit-scrollbar常失效，因安卓webview和ios16.4前safari不支持该伪元素；ios16.4+仅有限支持，android基本不支持；替代方案是禁用原生滚动条并用css+js自定义实现。
移动端 ::-webkit-scrollbar 为什么经常失效
因为绝大多数安卓 WebView 和 iOS Safari（iOS 16.4 之前）根本不支持 ::-webkit-scrollbar 伪元素。你写的 ::-webkit-scrollbar-track、::-webkit-scrollbar-thumb 在真机上大概率完全不渲染——不是写错了，是浏览器压根没实现。
常见错误现象：overflow: scroll 滚动正常，但自定义样式全无；开发者工具里能看到伪元素被识别，但无任何视觉反馈；iOS 模拟器可能显示，真机却空白。
- iOS 16.4+ 才开始有限支持
::-webkit-scrollbar，且仅限于部分场景（如<div> 容器，非 <code>或textarea） - Android Chrome / WebView 基本不支持，哪怕加了
-webkit-appearance: none也无效 - 即使支持，
thumb的最小高度/宽度有硬限制（通常 ≥ 20px），小容器里容易消失 - 先禁用原生滚动条干扰：
element { scrollbar-width: none; -ms-overflow-style: none; }（仅对 Firefox / IE 有效，但无害） - 关键一步：用
overscroll-behavior: contain防止滚动穿透（比如弹窗内滚动到底部时触发背景页滚动） - 给容器设
position: relative，再用绝对定位的<div class="scrollbar-thumb"> 模拟拖块，通过 JS 同步 <code>scrollTop和高度比例scrollTop和scrollHeight计算滚动条位置的坑手动实现滚动条时，
scrollTop / (scrollHeight - clientHeight)这个比值看似简单，但在移动端极易出错——因为clientHeight可能包含缩放、字体渲染差异或动态内容重排导致的抖动。性能影响：频繁读取这些属性会强制同步布局（layout thrashing），造成卡顿，尤其在低端 Android 机上明显。
- 别在
scroll事件里直接计算并更新 thumb 位置；改用requestAnimationFrame节流 -
scrollHeight在内容异步加载（如图片懒加载）后可能变化，需监听resize或用MutationObserver监控子节点变动 - iOS 上
scrollTop可能为小数，但transform: translateY()对 subpixel 渲染不友好，建议四舍五入到整数像素
要不要用第三方库？比如
simplebar或overlay-scrollbars如果项目已用 Webpack/Vite 且允许引入依赖，
simplebar是目前最轻量（~5KB gzip）、移动端适配最稳的选择；overlay-scrollbars功能更全但体积翻倍，且默认启用触摸惯性，有时和业务手势冲突。兼容性底线：两者都 fallback 到原生滚动（无样式），不会让滚动失效。
-
simplebar默认隐藏原生条，自动处理touchstart/touchmove，但需注意它会给容器加overflow: hidden，可能影响内部position: fixed元素定位 - 避免在
body上直接初始化——iOS Safari 对body滚动的控制逻辑特殊，推荐只作用于明确的<div class="js-simplebar"> <li>若只需样式微调（比如加个圆角、改个颜色），别上库；纯 CSS <code>scrollbar-color（Firefox）+scrollbar-width已够用，只是覆盖范围窄
移动端滚动条样式这件事，真正麻烦的从来不是怎么画那个条，而是得同时应付三套渲染逻辑：WebKit 的半残支持、Blink 的静默忽略、以及 iOS 对 touch-scroll 的私有优化。动手前先查
navigator.userAgent和实际机型测试，比堆 CSS 属性实在得多。 - 别在
替代方案：用 overscroll-behavior + 自定义滚动容器
与其死磕伪元素，不如用 CSS 原生能力控制滚动行为，再配合轻量 JS 实现可样式化的滚动条。核心是绕过系统滚动条，自己画一个“假条”并绑定真实滚动位置。
使用场景：列表页、弹窗内长内容、仪表盘侧边栏等需要统一 UI 风格的区域。
