Firefox 仅支持 scrollbar-color 和 scrollbar-width，Chrome/Edge/Safari 仅支持 ::-webkit-scrollbar 伪元素；两者互不兼容，需分别适配，跨浏览器一致定制本质是妥协方案。
scrollbar-color 在 Firefox 里才生效
这个属性根本不是全浏览器通用的，它只在 Firefox（包括桌面版和 Android 版 Firefox）中起作用。Chrome、Edge、Safari 都完全忽略 scrollbar-color，写了也没用。
常见错误现象：scrollbar-color: #ff6b6b #f0f0f0; 在 Chrome 里一点反应都没有，开发者以为写错了 CSS，其实只是浏览器不支持。
- Firefox 支持值为两个颜色：第一个是滑块（thumb）色，第二个是轨道（track）色
- 必须配合
scrollbar-width使用才有意义（比如设为thin或auto） - 不能用于自定义滚动条整体结构（比如加圆角、阴影），仅限颜色
Chrome/Edge/Safari 只能靠 ::-webkit-scrollbar 伪元素
这些基于 Blink 或 WebKit 的浏览器，只认 ::-webkit-scrollbar 系列伪类。这不是标准，但目前唯一可行方案。
使用场景：需要在主流桌面浏览器统一控制滚动条外观时，必须用这套。
立即学习“前端免费学习笔记（深入）”；
-
::-webkit-scrollbar控制整个滚动条容器（宽度/高度） -
::-webkit-scrollbar-thumb控制滑块，支持background、border-radius、border -
::-webkit-scrollbar-track控制轨道背景，注意默认有内边距，常需background-clip: padding-box修正 - 移动端 Safari 对
::-webkit-scrollbar支持极差，iOS 16+ 才开始部分支持，且仅限于某些容器（如overflow: scroll的 div），不适用于 body
body 滚动条样式在 Chrome 里容易失效
给 body 直接写 ::-webkit-scrollbar 规则，经常没效果——因为实际滚动容器可能是 html，或被框架（如 React Router、Next.js）生成的 wrapper 节点截断了。
性能影响：伪元素规则如果写得太宽泛（比如 *::-webkit-scrollbar），可能触发重绘开销，尤其在复杂页面中。
- 优先对具体容器设置
overflow: scroll，再对其应用伪元素样式，更可控 - 检查 computed styles，确认滚动行为是否真的发生在预期元素上（右键审查元素 → 查看“Layout”或“Computed”里的 overflow 和 writing-mode）
- 避免在
body上依赖::-webkit-scrollbar-thumb:hover做交互反馈，hover 状态在触屏设备上不可靠
滚动条宽度/显示逻辑受系统设置干扰
macOS 默认隐藏滚动条（只在滚动时出现），Windows 默认常驻，Linux 各发行版不一。CSS 设置的 width 或 scrollbar-width: thin 可能被系统策略覆盖。
容易踩的坑：本地开发看着正常，上线后用户说“看不到滚动条”，其实是系统设置了“自动隐藏”，而你的 ::-webkit-scrollbar 没配 opacity 或 transition 来适配这种状态切换。
- Firefox 的
scrollbar-width: thin在 macOS 上可能被无视，仍显示默认宽度 - Chrome 不支持
scrollbar-width，只能靠::-webkit-scrollbar的 width 属性模拟，但最小宽度约 8px，无法真正“隐藏” - 无障碍需求下，强行隐藏滚动条（如 opacity: 0）会破坏屏幕阅读器和键盘导航体验，不建议这么做
