答案：需分浏览器采用不同方案——Firefox仅支持scrollbar-width和scrollbar-color，Chrome/Edge/Safari支持::-webkit-scrollbar，iOS Safari完全不支持；必须用@supports隔离规则，避免兼容性冲突。
没有“统一”的滚动条样式方案，只有分层妥协的兼容策略：Firefox 只认 scrollbar-width 和 scrollbar-color，Chrome/Edge/Safari（macOS）才响应 ::-webkit-scrollbar，iOS Safari 基本不响应任何自定义。
为什么 ::-webkit-scrollbar 在 Firefox 和部分 Edge 版本里完全没反应
这不是 bug，是设计如此。::-webkit-scrollbar 是 WebKit/Blink 内核的私有伪元素，Firefox（Gecko）从不解析它——写了也静默忽略，控制台不报错、不警告。Edge 96+ 虽属 Blink，但对 scrollbar-width: thin 的支持仍不稳定，常回退到 auto。真要让 Firefox 显示细滚动条，只能靠 scrollbar-width: thin；想改颜色，只允许用 scrollbar-color: #888 #f5f5f5，顺序不能反，且无法调圆角、加阴影、设 hover 效果。
如何安全地同时写 WebKit 和 Firefox 样式而不互相干扰
关键在隔离 + 特性检测。别把 ::-webkit-scrollbar 和 scrollbar-width 放在同一规则块里，否则 Firefox 会因遇到不认识的伪类而跳过整条 CSS 规则（连带后面的 scrollbar-width 也不生效）。正确做法是：
- 用
@supports (scrollbar-width: thin)包裹 Firefox 专属声明 - 用
@supports selector(::-webkit-scrollbar)包裹 WebKit 专属样式（注意：Safari 16.4+ 才稳定支持该selector()检测） -
::-webkit-scrollbar里禁止使用 CSS 变量或calc()，所有宽高、颜色必须写死值 - 移动端 iOS Safari 对
::-webkit-scrollbar-thumb:hover支持极差，建议直接省略 hover 状态
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，这些会触发高频重绘，造成滚动卡顿
真正需要强一致体验时，该不该上 JS 滚动库
当项目明确要求“所有浏览器滚动条外观、行为完全一致”，比如金融后台或设计系统文档站，那就得接受 JS 方案的代价：perfect-scrollbar 或 simplebar 确实能绕过浏览器限制，但它们会接管原生滚动逻辑，带来三个硬伤：
- 屏幕阅读器可能无法同步感知滚动位置变化，WCAG 2.1 AA 合规风险上升
- 惯性滚动、触控板自然滚动、键盘 PageDown 行为都会被重写，体验割裂
- 每个滚动容器都要初始化实例，DOM 节点多时内存占用明显增加
多数情况下，用 scrollbar-width: thin + scrollbar-color 保底，再给 Chrome/Safari 加一层 ::-webkit-scrollbar 精修，已是当前技术约束下的最优解。真正难处理的不是样式，而是 Safari 对 ::-webkit-scrollbar-track 的渲染抖动和 Firefox 在 Win10/Win11 下滚动条占位宽度不一致——这两个问题至今无纯 CSS 解法，只能靠用户系统设置或引导升级。
