macOS 下滚动条“看不见”不是 bug，是系统级行为：Chrome 和 Safari 默认启用 overlay scrollbar，仅悬停或滚动时显示；Flex 子项需设 min-height: 0 才触发 overflow:auto；横向滚动需内容真实溢出且容器有明确宽度；body 上乱设 overflow 会拦截子级滚动。
macOS 下滚动条“看不见”不是 bug，是系统级行为
Chrome 和 Safari 在 macOS 上默认启用“优雅滚动”（overlay scrollbar）：滚动条轨道仅在悬停或滚动时淡入，静止状态下完全透明。你用滚轮或触控板能正常滚动，但视觉上像没滚动条——这不是 overflow:auto 失效，而是浏览器遵从系统策略。
Windows 则不同：滚动条始终常显，只要内容溢出，overflow:auto 就会渲染可见的轨道和滑块。
- 调试时别只看眼睛，先用触控板/滚轮试试能否滚动
- 若需强制常显，必须加 WebKit 专属样式：
.container::-webkit-scrollbar { display: block; } - Firefox 在 macOS 上不支持
::-webkit-scrollbar，只能用scrollbar-width: thin或auto，无法完全自定义外观
为什么 overflow:auto 在 Flex 子项里容易“失效”
Flex 容器的子项默认有 min-height: auto，它会阻止子项收缩，导致即使设了 max-height 和 overflow-y: auto，内容仍被撑开、不触发溢出判定。
常见于 Spotify 克隆这类布局：外层 display: flex + flex-direction: column，中间区域想纵向滚动，但滚动条死活不出现。
立即学习“前端免费学习笔记（深入）”；
- 必须给该子项加
min-height: 0（或height: 0），让溢出计算生效 - 配合
flex: 1，确保它占满剩余空间又不无限拉伸 - 避免单独设
flex-shrink: 0，这会让子项拒绝压缩，反而顶开父容器
overflow-x: auto 横向滚动条不显示的三个硬条件
overflow-x: auto 不像纵向滚动那样“友好”，它对内容宽度是否真实溢出极其敏感，且 macOS 下更难察觉。
- 子元素必须真正超出容器宽度：比如用
white-space: nowrap或min-width: 120%强制撑宽，不能只靠内容多 - 父容器必须有明确的
width或max-width，否则宽度自适应，永远不溢出 - macOS 下横向滚动条同样被隐藏，需额外加
.container::-webkit-scrollbar { display: block; height: 8px; }（注意是height，不是width）
别在 body 上乱设 overflow:auto
某些 UI 框架（如 Modal 组件）会在打开时给 <body> 加 overflow: hidden，结果连内部设置了 overflow:auto 的区域也一并禁用滚动——因为滚动事件被父级拦截了。
更隐蔽的是：如果 <body> 自身设了 overflow:auto，整页滚动逻辑会被覆盖，页面可能卡死或无法滑动。
- 滚动区域必须独立于
<body>的滚动控制链 - 检查 computed styles，确认目标元素的
display是block或inline-block，而非flex或grid（否则overflow作用对象可能错位） - 绝对定位元素（
position: absolute）脱离文档流，不会参与父容器高度计算，也会导致“看似没溢出”
overflow:auto 单方面决定的；它依赖容器边界、内容尺寸、父级约束、系统策略四者同时满足。最容易被忽略的是：macOS 下“不可见 ≠ 不可用”，以及 Flex 子项里 min-height: 0 这个看似无关的开关。 
