overflow: hidden 失效主因是父容器无明确宽高或子元素脱离文档流；需触发BFC（如display: flow-root）、避免absolute/floating、注意iOS Safari兼容性及box-sizing对可用空间的影响。
overflow: hidden 为什么没生效
最常见的原因是父容器没有设定明确的宽高，或者内部元素脱离了文档流。CSS 的 overflow 只对「块级格式化上下文（BFC）」起作用，而浮动、绝对定位等会让子元素“逃出”父容器的约束范围。
实操建议：
- 给父容器加
display: block或display: flow-root（推荐，现代浏览器兼容好，能强制创建 BFC） - 检查是否有
position: absolute子元素——它不参与父容器高度计算，overflow: hidden对它裁剪无效，除非父容器也设了position: relative - 避免用
float布局，浮动会破坏 BFC，此时即使写了overflow: hidden，也可能只清浮动而不裁剪
overflow: hidden 和 box-sizing 的关系
box-sizing 决定的是「内容区 + 内边距 + 边框」是否被算进 width/height，但它不影响 overflow 的裁剪边界。裁剪始终以盒模型的「border box」外边缘为界——也就是你写的 width 和 height 所定义的那圈线。
容易踩的坑：
立即学习“前端免费学习笔记（深入）”；
- 设了
box-sizing: border-box但忘了 padding，结果内容被裁掉一部分，误以为是overflow问题，其实是可用空间比预期小 - 设了
box-sizing: content-box（默认），又给了大 padding，实际渲染宽度超出设定值，overflow: hidden会把多出来的部分切掉，但开发者常意识不到是 padding 导致的溢出 - 边框（
border）哪怕只有 1px，也会压缩内容区域；如果没预留空间，文字或图片可能直接被裁在边框内侧
移动端 Safari 下 overflow: hidden 失效的典型场景
iOS Safari 对 overflow: hidden 的支持有历史遗留问题，尤其在 body 或 html 上直接设置时，滚动惯性、弹性滚动（rubber-banding）会绕过裁剪逻辑。
真实使用场景：
- 做模态框遮罩层，想禁止背后页面滚动，仅靠
body { overflow: hidden }在 iOS 上大概率失效 - 轮播图容器设了
overflow: hidden，但手指快速滑动时仍能看到相邻项“闪出”
解决办法：
- 对遮罩层父容器用
position: fixed; width: 100%; height: 100%，再配overflow: hidden，比操作body可靠 - 轮播类组件，确保容器有
-webkit-overflow-scrolling: touch（虽然已废弃，但在旧版 Safari 中仍影响裁剪行为） - 必要时加
touch-action: none阻断默认手势，但要小心影响可访问性
用 overflow: hidden 实现“隐藏但保留占位”的误区
很多人以为 overflow: hidden 能替代 visibility: hidden 或 display: none，其实它只是视觉裁剪，元素仍在文档流中，尺寸、margin、事件响应都照常发生。
关键区别：
-
overflow: hidden不影响getBoundingClientRect()返回的尺寸，也不阻止click事件穿透到被裁区域（比如按钮一半被裁，点击露出部分仍可触发） - 若想“隐藏且不占空间”，必须用
display: none；若想“隐藏但保持尺寸和事件”，才用visibility: hidden - 动画中滥用
overflow: hidden做入场效果（如从左滑入），要注意父容器必须有明确宽高，否则动画路径不可控
复杂点在于：裁剪不是渲染优化，它不减少重排重绘成本。一个 5000px 宽的图片放进 200px 容器并设 overflow: hidden，浏览器依然要解码、布局、绘制整张图——只是最后只显示其中一截。
