没有通用方案解决滚动条样式不一致，必须分浏览器隔离声明：Firefox用@supports(scrollbar-width:thin)配scrollbar-width/color，Chrome/Edge用@supports selector(::-webkit-scrollbar)配WebKit伪元素，且需注意安全上下文与移动端限制。
没有“解决不一致”的通用方案，只有分浏览器隔离声明——Firefox 和 Chrome 的滚动条控制机制完全不同，混写规则会导致一方静默失效。
为什么 ::-webkit-scrollbar 在 Firefox 里完全没反应
这不是 bug，是内核设计决定的：::-webkit-scrollbar 是 WebKit/Blink 私有伪元素，Firefox（Gecko）根本不解析它。写了也不会报错、不警告，整条 CSS 规则块直接被跳过。
- 哪怕你把它和
scrollbar-width写在同一{}里，Firefox 也会因不认识前者而丢弃整个规则块——连带后面的scrollbar-color也失效 - Chrome 也不理解
scrollbar-width的语义（部分版本能解析但行为不可靠），所以不能指望它“兼容”Firefox 的写法 - 别用
@supports (scrollbar-color: #888 #f5f5f5)检测——旧版 Edge 会误判为 true，导致样式错误加载
必须用 @supports 分开包裹，且检测方式要精准
Firefox 专属样式只能放在 @supports (scrollbar-width: thin) 块里；WebKit/Blink 专属样式必须用 @supports selector(::-webkit-scrollbar) 包裹——这是目前最准的检测方式，比 @supports (-webkit-appearance: none) 更可靠。
-
@supports (scrollbar-width: thin)块中只放scrollbar-width和scrollbar-color，顺序固定：scrollbar-color: <thumb> <track>，写反了就无效 -
@supports selector(::-webkit-scrollbar)块中只放::-webkit-scrollbar及其子伪元素（::-webkit-scrollbar-track、::-webkit-scrollbar-thumb等），漏掉::-webkit-scrollbar容器本身，滑块可能尺寸为 0 - 所有
::-webkit-scrollbar相关宽高、颜色必须写死值，不支持var(--color)或calc()
Chrome 120+ 下 ::-webkit-scrollbar 突然失效的真正原因
不是代码错了，是运行环境不被信任：Chrome 120+ 默认禁用非安全上下文下的自定义滚动条样式，file://、HTTP 页面、甚至未配 HTTPS 的 http://dev.example.com 全部被拦截，样式静默丢弃，控制台零提示。
立即学习“前端免费学习笔记（深入）”；
- 唯一可调试的合法环境是
https://或http://localhost（含端口，如localhost:3000） - 父容器若设了
overflow: hidden或transform，会创建新层叠上下文，滚动条可能被裁剪或不可见 -
::-webkit-scrollbar-thumb中避免box-shadow、filter、background-image，这些触发高频重绘，滚动卡顿明显
iOS Safari 和 Android Chrome 的现实约束
iOS Safari 完全不响应 ::-webkit-scrollbar，Android Chrome 默认禁用且用户无法唤出滚动条——对响应式容器默认启用自定义样式，大概率白忙一场。
- 别指望
scrollbar-color在 iOS Safari 或旧 Edge 中生效，它只在 Firefox 和少数新版 Chromium 中被部分实现 - Safari 16.4+ 才开始有限支持
::scrollbar-thumb等标准伪类，旧版仍只能靠::-webkit-scrollbar - 移动端优先考虑交互体验而非视觉定制；如果必须统一，建议用轻量 JS 模拟滚动条，而不是强依赖 CSS 伪元素
最容易被忽略的一点：scrollbar-width: none 后滚动依然可用（滚轮、拖拽、键盘方向键都有效），只是视觉隐藏——很多人误以为“失效”，其实是预期之外的可用性保留。
