直接给body或html写::-webkit-scrollbar基本无效，因该伪元素仅对显式设置overflow且内容真实溢出的块级容器生效；需绑定具体容器（如.list-container）、成套定义track/thumb、Firefox须用scrollbar-width和scrollbar-color配对声明。
直接给 body 或 html 写 ::-webkit-scrollbar 样式基本无效，这不是漏写了，是浏览器压根不认——滚动条样式只对「实际触发滚动的块级容器」生效，且必须满足 overflow 显式设置 + 内容真实溢出两个条件。
为什么局部容器的滚动条样式不生效
常见错误是把 ::-webkit-scrollbar 选择器写在全局作用域（比如 :root 或未加类名的 div），但该伪元素不继承、不冒泡，必须绑定到具体设置了 overflow: auto 或 scroll 的容器上。
-
.list-container { height: 300px; overflow-y: auto; }是前提，没这句，后续所有::-webkit-scrollbar都不会触发渲染 - 漏掉
::-webkit-scrollbar-track或::-webkit-scrollbar-thumb中任意一个，Chrome/Edge 会整套回退到系统默认样式（不是“部分失效”，是完全不走自定义逻辑） - 移动端 Safari 对
::-webkit-scrollbar支持极弱，iOS 16+ 才开始有限支持，且不响应:hover，别指望悬停变色
如何让自适应容器（如 100% 宽高）正确显示滚动条
用 100vh 或 100% 做高度时，容易因父级未设高或 margin/padding 干扰，导致内容不溢出、滚动条不出现。关键不是“撑满”，而是“强制预留可滚动空间”。
- 父容器必须有明确高度约束：
height: 100vh或max-height: 100vh，不能只靠min-height - 子容器用
flex: 1; overflow-y: auto替代固定height，避免计算误差导致滚动失效 - 若内容是 flex 布局横向排列（如画廊），需加
white-space: nowrap和overflow-x: auto，否则换行会掩盖横向滚动需求 - Windows 下滚动条默认占位 17px，若要“不挤内容”，得用
padding-right: 17px或外层容器width: calc(100% + 17px)补偿（Firefox 不吃这个套路，得单独处理）
Firefox 和 WebKit 的兼容写法怎么组织
Firefox 完全无视 ::-webkit-scrollbar，只认 scrollbar-width 和 scrollbar-color，而且这两个属性只对根滚动容器（html、body）或设置了 overflow 的块级元素生效，对嵌套 div 滚动无效。
立即学习“前端免费学习笔记（深入）”；
- 基础写法必须成对出现：
scrollbar-width: thin是前提，只有它设为thin或auto，scrollbar-color才会起作用；设none就彻底隐藏，颜色设置被忽略 -
scrollbar-color: #6c5ce7 #f0f0f0顺序不能反，第一个是滑块色，第二个是轨道色；transparent可用于隐藏轨道，但不推荐，视觉上易误判是否可滚动 - 不要写
::-moz-scrollbar——这个伪类早在 Firefox 64 就废弃了，查 DOM 也找不到对应节点 - 如果真需要跨浏览器一致（比如设计稿强要求圆角+阴影），别硬刚原生，用
simplebar这类 JS 库接管更省事，它自动检测内核并注入虚拟滚动条
最常被忽略的一点：滚动条是否“可见”和是否“可用”是两回事。用 scrollbar-width: none 或 ::-webkit-scrollbar { display: none } 后，用户仍能滚轮/触控/键盘滚动，只是没了视觉反馈——这对无障碍访问很不友好，上线前务必确认产品是否允许这种降级。
