移动端滚动条无法真正美化，iOS Safari完全无视所有滚动条CSS，Android Chrome仅部分支持::-webkit-scrollbar且需满足overflow显式设置等前提，Firefox for Android则需用scrollbar-width和scrollbar-color。
移动端滚动条无法真正“美化”，只能在有限支持的场景下做视觉收敛或隐藏；iOS Safari 完全无视所有滚动条 CSS，这是硬限制，不是兼容性问题。
Android Chrome 支持 ::-webkit-scrollbar 但有边界
部分 Android 设备（尤其是 Chrome 和基于 Chromium 的 WebView）能识别 ::-webkit-scrollbar 系列伪元素，但必须满足几个前提：
- 容器需显式设置
overflow-y: scroll或overflow-x: scroll，auto在某些版本中会跳过样式渲染 -
::-webkit-scrollbar-track必须设background，否则透明——深色背景上直接消失 -
::-webkit-scrollbar-thumb的border-radius不能超过height / 2（水平滚动条则看width / 2），否则被裁切 - 移动端无 hover 状态，
::-webkit-scrollbar-thumb:hover无效，别写
示例（仅对 Android 生效）：
.chat-list {
overflow-y: scroll;
height: 300px;
}
.chat-list::-webkit-scrollbar {
width: 6px;
}
.chat-list::-webkit-scrollbar-track {
background: #f5f5f5;
border-radius: 3px;
}
.chat-list::-webkit-scrollbar-thumb {
background: #999;
border-radius: 3px; /* 6px / 2 = 3px，刚好 */
}
Firefox for Android 需用 scrollbar-width 和 scrollbar-color
Firefox 移动版不认 ::-webkit-scrollbar，只响应标准属性，且只在 <html> 或 <body> 上生效——写在局部容器里完全没反应：
立即学习“前端免费学习笔记（深入）”；
-
scrollbar-width: thin是唯一能让滚动条倾向常驻的开关；auto下它可能一闪而过甚至不出现 -
scrollbar-color: #6c5ce7 #f0f0f0仅控制滑块色和轨道色，不支持圆角、渐变、阴影 - 这两个属性必须成对使用，单独写一个无效
正确写法（影响整页）：
html {
scrollbar-width: thin;
scrollbar-color: #6c5ce7 #f0f0f0;
}
iOS Safari：所有滚动条 CSS 均失效，接受它
这不是 bug，是苹果明确的设计决策。无论你写多少 ::-webkit-scrollbar、scrollbar-color，还是加 @supports 检测，iOS Safari（含 iPadOS）统统忽略。
- 测试时不能用 macOS Safari 代替 iOS 测试——两者渲染逻辑完全不同
-
-webkit-overflow-scrolling: touch虽已废弃，但在 iOS 上仍提供惯性滚动，但它会让原生滚动条彻底不可见，且不触发任何自定义样式 - 若页面强依赖横向滚动（如时间轴、宽表格），建议用
overflow-x: scroll+scroll-behavior: smooth+ 视觉引导（如右端渐变遮罩、箭头图标）暗示可滑动
真要统一外观？JS 库是唯一路径，但代价明确
SimpleBar、OverlayScrollbars 这类库能接管滚动逻辑，在 Android 显示自定义滚动条，iOS 则退化为无滚动条但可滑动的“隐形滚动”模式。
- 它们会替换原生
overflow行为，改用position: absolute+transform模拟滚动，可能影响性能和可访问性（如屏幕阅读器焦点流） - 滚动事件监听需从
scroll改为库提供的scroll或scrollStart钩子 - 若项目已重度依赖原生滚动（比如配合
IntersectionObserver做懒加载），引入 JS 滚动库容易引发冲突
复杂点在于：你得在“视觉一致”和“行为保真”之间做取舍——iOS 用户看不到滚动条，但滚动本身必须丝滑、可预测；Android 用户看到滚动条，但它的尺寸、位置、拖拽反馈必须跟原生体验接近，否则反而造成认知负担。
