::-webkit-scrollbar仅在Chrome/Edge/Safari生效，Firefox需用scrollbar-width和scrollbar-color；二者语法、作用范围及能力不同，须用@supports检测并分写样式。
Chrome/Firefox中::-webkit-scrollbar为什么没效果
因为::-webkit-scrollbar只在基于WebKit/Blink的浏览器（Chrome、Edge、Safari）中生效，Firefox完全不支持该伪元素——它用的是scrollbar-width和scrollbar-color这两个CSS属性。如果你在Firefox里写了::-webkit-scrollbar却没看到变化，不是写错了，是根本没被解析。
实操建议：
- 先用
@supports (scrollbar-width: auto)或@supports selector(::-webkit-scrollbar)做特性检测，再分条件写样式 - 不要只依赖
::-webkit-scrollbar一套规则去“覆盖所有浏览器” - 移动端Safari对
::-webkit-scrollbar支持极弱（iOS 16前基本无效），别在响应式滚动容器里默认启用
scrollbar-width和scrollbar-color能控制什么
这是Firefox（以及新版Edge/Chrome在某些模式下也部分识别）的原生方案，只能控制滚动条的“粗细”和“颜色组合”，不能自定义轨道形状、滑块圆角、阴影等细节。
可用值说明：
立即学习“前端免费学习笔记（深入）”；
-
scrollbar-width: auto | thin | none：分别对应默认宽度、窄滚动条、隐藏滚动条（内容仍可滚动） -
scrollbar-color: <thumb-color> <track-color>：第一个是滑块色，第二个是轨道色，不支持渐变或透明度（rgba(0,0,0,0.5)会被忽略） - 这两个属性必须写在根滚动容器上（如
html、body，或设置了overflow: auto的div），不能写在子元素里
::-webkit-scrollbar各部分伪元素怎么配对使用
WebKit系浏览器提供了一组伪元素来逐层控制滚动条外观，但它们之间有隐含的层级依赖和默认尺寸限制，乱套用容易导致滑块消失或无法拖动。
关键组合与注意事项：
-
::-webkit-scrollbar：整体容器，设width或height（横/竖滚动条），不设则用浏览器默认（通常17px） -
::-webkit-scrollbar-track：轨道背景，建议加border-radius和background-clip: padding-box避免圆角被裁切 -
::-webkit-scrollbar-thumb：滑块，必须设background-color，否则透明不可见；border-radius推荐用999px实现真圆角（而非8px这种固定值，因高度动态变化） -
::-webkit-scrollbar-button和::-webkit-scrollbar-corner极少需要，且容易引发兼容性问题，非必要不碰
自定义滚动条后常见交互失效怎么办
最典型的是：滑块拖不动、鼠标滚轮失灵、触屏无法滑动、scrollIntoView()跳转错位——这些问题往往不是样式本身导致，而是触发了浏览器的“非标准滚动行为降级”。
排查要点：
- 确保容器有明确的
height或max-height，且overflow-y: auto（不能是scroll） - 避免给
::-webkit-scrollbar-thumb设transition动画，某些Chrome版本会因此卡住拖拽事件流 - 如果用了
scrollbar-width: none又希望保留键盘↑↓滚动，得额外监听keydown并手动scrollTop，因为隐藏后焦点滚动逻辑可能被绕过 - React/Vue项目中，若滚动容器是虚拟列表（如
react-window），自定义滚动条样式需作用于其内部scrollableNode，而不是外层wrapper
滚动条样式看似只是视觉调整，但实际牵扯渲染管线、事件分发和可访问性支持。哪怕只是改个颜色，也要验证键盘导航、屏幕阅读器播报、触控反馈是否还正常——这些地方最容易被忽略。
