::-webkit-scrollbar { display: none } 有时滚动失效，是因为旧版 Safari 和部分 Chromium 会连带抑制滚动交互区域响应，尤其在 position: absolute 或 contain: paint 下；必须配合 overflow: auto/scroll 且内容真实溢出，否则伪元素不生成，该规则无从生效。
直接用 ::-webkit-scrollbar { display: none } 为什么有时滚动失效？
这不是 bug，而是浏览器渲染机制决定的：当 display: none 应用于 ::-webkit-scrollbar 时，部分旧版 Safari（iOS 15 及更早）和某些 Chromium 版本会连带抑制滚动交互区域的响应，尤其在 position: absolute 容器或 contain: paint 上下文中容易被跳过。
- 必须确保目标元素同时设置了
overflow: auto或overflow: scroll，且内容实际溢出——否则伪元素根本不生成，display: none无从生效 - 不要把
::-webkit-scrollbar { display: none }和overflow写在不同选择器、不同 CSS 文件中；Safari 16.4+ 要求二者在同一计算样式链上才可靠触发 - 若仍失效，降级改用
width: 0; height: 0; background: transparent更稳妥，它不依赖渲染层剔除逻辑
overflow: hidden 和隐藏滚动条是两回事
很多人看到“隐藏滚动条”就下意识写 overflow: hidden，结果页面彻底不能滚。这是根本性误解：overflow: hidden 是关闭滚动能力本身，不是隐藏 UI 元素。
-
overflow: hidden会裁剪溢出内容，且禁用所有滚动方式（鼠标滚轮、键盘、触摸板拖拽全失效） - 真正要的是
overflow: auto或overflow: scroll—— 它们开启滚动上下文，才是“保留滚动功能”的前提 - 如果只想要垂直方向隐藏，用
overflow-y: auto; overflow-x: hidden，但注意overflow-x: hidden仍会阻止水平滚动，不是“仅隐藏条”
Firefox 中 scrollbar-width: none 不生效的典型场景
这个属性只对 Firefox 64+ 有效，且非常挑剔容器状态。写上却没反应，大概率是以下某个条件没满足：
- 目标元素没有显式
height或max-height，Firefox 不认为需要滚动，自然不渲染滚动条，也就不触发隐藏逻辑 - 选择器命中的是父容器，但真正可滚动的是子
div（比如用了flex布局，滚动发生在内部 item 上） - 和
overflow: hidden共存——后者直接压制滚动行为，scrollbar-width失去作用对象 - 写在
body或html上时，需确认是否被用户代理样式或框架 reset 覆盖（检查 computed style 中scrollbar-width是否为none）
移动端 Safari 的隐藏滚动条陷阱
iOS Safari 对 ::-webkit-scrollbar 的支持直到 iOS 16 才趋于稳定，此前版本存在大量不可靠行为：
立即学习“前端免费学习笔记（深入）”；
- 即使写了
display: none，快速滑动时仍可能闪现滚动条（尤其是overflow: auto+ 动态内容加载场景） - 未设置
-webkit-overflow-scrolling: touch（虽然 iOS 15+ 已弃用，但部分机型仍依赖它激活原生滚动惯性） - 使用
transform: translateZ(0)或will-change: scroll-position可能干扰伪元素渲染，导致隐藏失效 - 真机调试时，务必禁用样式缓存（Cmd+Shift+R 强制刷新），Safari 会对
display: none的滚动条做样式缓存，本地改了也不生效
overflow 上。任何脱离 overflow: auto/scroll 谈“隐藏但可滚”，都是空中楼阁。最常被忽略的，是开发者改完 CSS 后没验证内容是否真的溢出、容器高度是否固定、以及是否意外继承了父级的 overflow: hidden。 
