overflow: hidden 失效主因是容器实际宽度超出视口，常见于 box-sizing: content-box、white-space: nowrap、伪元素/字体微溢出等；应统一用 border-box、检查 margin、用 max-width: 100% 替代 width: 100%，并优先修复布局缺陷而非掩盖滚动条。
为什么 overflow: hidden 有时根本没用？
直接加 overflow: hidden 却仍有横向滚动条，大概率不是样式没生效，而是容器实际宽度超出了视口。常见原因包括：box-sizing 默认是 content-box，导致 padding 或 border 被额外加到 width 上；或者子元素用了 white-space: nowrap、display: inline-block 且未设 vertical-align，引发隐式换行失效和溢出；还有可能是伪元素（如 ::before）或字体渲染产生的微小溢出（尤其在 Safari 中）。
实操建议：
- 所有根级容器统一加 box-sizing: border-box
- 检查是否有未重置的 margin（比如 body 默认外边距）
- 用浏览器开发者工具的「Layout」面板看真实尺寸，别只信 width: 100%
用 max-width: 100% 替代 width: 100% 更安全
width: 100% 是相对于父容器计算的，但若父容器本身因 padding/border 超出视口，子元素照样溢出；而 max-width: 100% 会强制限制其最大可用宽度为包含块的 content area 宽度，更贴合响应式意图。
典型场景：
- 图片、iframe、表格等固有宽高比元素
- 嵌套的 flex/grid 容器内部子项
- 第三方组件（如地图 SDK 的容器）无法修改内部结构时
示例：
.responsive-img {<br> max-width: 100%;<br> height: auto;<br>}
移动端 Safari 的 overflow: hidden 失效问题
iOS Safari 对 overflow: hidden 在 body 或 html 上的处理很特殊：它不会阻止页面整体横向滚动，尤其当存在 input 聚焦、键盘弹出或缩放操作后。这不是 bug，是 WebKit 的渲染策略。
在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。
立即学习“前端免费学习笔记（深入）”；
绕过方法：
- 避免对 html 或 body 设 overflow: hidden，改用固定高度的 wrapper 容器
- 添加 touch-action: pan-y 阻止横向拖拽
- 必须锁屏时，配合 JavaScript 监听 scroll 并 preventDefault()（注意 iOS 16+ 需要 passive: false）
- 检查是否启用了 viewport 的 user-scalable=yes，临时禁用可缓解
真正要控制的是「内容流」，不是靠隐藏滚动条
把 overflow: hidden 当成万能解药，容易掩盖布局缺陷。比如 flex 子项未设 flex-shrink: 1，或 grid 列用 minmax(200px, 1fr) 却没配 overflow: hidden 内容，都会在小屏上撑破容器。
优先检查：
- 是否所有文本都设置了 word-break: break-word 或 overflow-wrap: break-word
- 表格是否加了 table-layout: fixed 和 width: 100%
- 是否存在未约束的 min-width（如 min-width: 320px）
- 使用 vw 单位时，是否考虑了滚动条宽度（约 15px），导致实际超出 100vw
滚动条不是敌人，它是用户界面的一部分。强行隐藏却不管内容适配，最终会在某些设备或系统设置下暴露得更彻底。
