做不到完全统一，但可用WebKit伪元素与Firefox标准属性两套规则覆盖99%用户：前者控制Chrome/Safari/Edge滚动条的尺寸、圆角、颜色等精细样式，后者在Firefox中仅支持scrollbar-width（auto/thin/none）和scrollbar-color（仅thumb/track双色），二者必须并行声明且互不干扰。
做不到完全统一，但可以用两套规则覆盖 99% 的真实用户场景：WebKit 伪元素 + Firefox 标准属性，缺一不可。
为什么不能只写 ::-webkit-scrollbar
只依赖 ::-webkit-scrollbar 系列伪元素，Firefox 用户看到的仍是原生滚动条——不是颜色不对，是根本没生效。Firefox 从不解析这些伪元素，连警告都不会报。更麻烦的是，Chrome 121+ 虽然开始支持 scrollbar-width 和 scrollbar-color，但它仍只把它们当作“补充控制”，不会替代 ::-webkit-scrollbar 的优先级。也就是说，两条路在 Chrome 里共存，但在 Firefox 里只认后者。
常见错误现象：
- 本地开发用 Chrome 测试完美，提测后 QA 在 Firefox 里反馈“滚动条还是默认灰粗条”
- 写了
::-webkit-scrollbar-thumb:hover，但 Firefox 用户 hover 没反馈，误以为交互失效
scrollbar-width 和 scrollbar-color 能做什么、不能做什么
这两个属性是 W3C 标准化路径，目前仅 Firefox 原生完整支持，Chrome 121+ 开始兼容（但 Safari 仍不支持）。它们能力有限，属于“够用但不够细”：
立即学习“前端免费学习笔记（深入）”；
-
scrollbar-width只接受auto、thin、none三个关键字，不支持具体像素值（如6px） -
scrollbar-color只能设两个颜色：thumb和track，不支持圆角、阴影、hover 状态、border-radius - 必须写在可滚动的元素上（如
html、body或带overflow: auto的容器），不能写在伪元素里
典型写法：
html {
scrollbar-width: thin;
scrollbar-color: #c1c1c1 #f5f5f5;
}
怎么让 WebKit 和 Firefox 规则互不干扰又各自生效
关键不是“覆盖”，而是“并行声明”。浏览器会自动忽略自己不支持的规则，所以你可以放心把两套都写上，只要注意作用域和优先级：
- 把
::-webkit-scrollbar规则放在全局（如html或body），避免被局部选择器权重压制 -
scrollbar-width和scrollbar-color必须写在同一个元素上，且该元素需有滚动行为（overflow: auto或scroll） - 不要试图用
@supports包裹::-webkit-scrollbar——它不支持条件检测，@supports selector(::-webkit-scrollbar)在部分浏览器中会直接失效 - 移动端 iOS Safari 支持
::-webkit-scrollbar，但滑块默认透明且无法 hover；Android Chrome 同样支持，但scrollbar-width: thin在某些版本下会被忽略
容易被忽略的细节：圆角、尺寸与 RTL 场景
很多人调完颜色就收工，结果上线发现 macOS 下滚动条圆角失效、或 RTL 页面（如阿拉伯语）里滑块位置反了：
-
::-webkit-scrollbar-thumb的border-radius在 macOS Safari 中需配合background-clip: padding-box才能真正生效，否则边缘发虚 -
::-webkit-scrollbar的width控制垂直滚动条，height控制水平滚动条；但水平滚动条在多数页面中不常出现，容易漏测 - RTL 布局下，
::-webkit-scrollbar-corner会出现在左下角而非右下角，如果设置了背景色，可能意外暴露角落区域 - Firefox 不支持
::-webkit-scrollbar-corner，也不支持scrollbar-color对角落着色——这意味着你无法统一右下角那个小方块的样式
最稳妥的做法是：把 ::-webkit-scrollbar-corner 显式设为 background: transparent，并在 Firefox 中接受它默认的空白状态。毕竟，那个角落本就极少被用户注意到。
