scrollbar-color 是 firefox 专属属性，chrome 等浏览器不支持，需用 ::-webkit-scrollbar 系列伪元素单独适配；两者必须双写、互不干扰，且移动端 safari 均不支持。
scrollbar-color 在 Firefox 中生效但 Chrome 无效？
因为 scrollbar-color 是 Firefox 专属的 CSS 属性，Chrome、Edge、Safari 完全不识别它。你写 scrollbar-color: #6c5ce7 #a29bfe; 在 Chrome 里不会报错，但也不会有任何效果——滚动条还是系统默认样式。
常见错误现象：在 Firefox 看起来正常，切到 Chrome 发现“没变”，以为是代码漏了或缓存问题。
- 只在 Firefox（64+）和基于 Gecko 的浏览器中支持
- Chrome/Edge/Safari 必须用
::-webkit-scrollbar系列伪元素实现 - 两者不能混用，也不互相兼容；必须分开写、分别测试
::-webkit-scrollbar 在 Chrome 中怎么写才不白忙活？
Chrome 系列浏览器用的是 WebKit 内核的私有伪元素，但它们对选择器匹配很敏感——写错一个层级或漏掉某部分，整个自定义就失效。
关键点不是“能不能写”，而是“写在哪”和“写全没写全”：
-
::-webkit-scrollbar控制整体轨道（必须设width或height，否则不可见） -
::-webkit-scrollbar-track是滑道背景，建议加background-color，否则可能透出页面底色 -
::-webkit-scrollbar-thumb是拖动块，至少要设background-color和border-radius，不然像一根灰柱子 - 必须作用于有滚动行为的容器（比如
overflow: auto的<div>），不能只写在 <code>body上指望全局生效（除非你真给body加了overflow）简单示例（仅对 class="scrollable" 的容器生效）：
scrollable::-webkit-scrollbar { width: 8px; } scrollable::-webkit-scrollbar-track { background-color: #f1f1f1; } scrollable::-webkit-scrollbar-thumb { background-color: #6c5ce7; border-radius: 4px; }想一套代码通吃 Firefox + Chrome？得双写且注意优先级
没有“自动降级”的魔法。你得同时提供两套规则，并确保它们互不干扰、各自生效。
容易踩的坑：
- 把
scrollbar-color和::-webkit-scrollbar写在同一选择器下，结果 Chrome 忽略前者、Firefox 忽略后者——这没问题，但很多人误以为要“合并写” - 忘记给 WebKit 规则加
!important（极少需要），反而在别的地方用了，导致样式被意外覆盖 - 在 CSS 预处理器里用嵌套写法，结果编译后
::-webkit-scrollbar被挂到错误父级下，失去作用 - 移动端 Safari 完全不支持这两者，iOS 滚动条永远不可见、不可定制——这点常被忽略
为什么改了颜色但滚动条还是“卡顿”或“消失”？
不是颜色问题，是滚动行为本身被影响了。自定义滚动条时最隐蔽的副作用就是触发重排或禁用硬件加速。
典型诱因：
-
::-webkit-scrollbar-thumb设置了opacity: 0.99或带transform，可能让浏览器放弃合成层，导致滚动掉帧 - 在
body上直接写::-webkit-scrollbar，而页面高度动态变化，某些情况下滚动条会“闪一下再消失” - Firefox 下
scrollbar-color对性能无影响，但如果你同时加了scrollbar-width: thin，部分旧版 Firefox（
验证方法：打开开发者工具 → 渲染面板 → 勾选“Paint flashing”，滚动看是否大面积高亮——有，说明重绘太频繁。
滚动条样式这事，表面是配色，实际是浏览器渲染链路的一次微小干预。越想“看起来一样”，越得接受各平台实现差异；越想“丝滑”，越得少动透明度和动画。
- 把
