overflow:hidden不能清除浮动，而是通过触发bfc使父容器包含浮动子元素高度，但会静默裁剪所有溢出内容，包括absolute定位菜单、box-shadow、transform延伸部分及伪元素装饰线。

overflow: hidden 会静默裁剪所有溢出内容

它不是“清除浮动”，而是靠触发 BFC 让父容器重新包含浮动子项，但代价是把超出父容器边界的内容全部切掉——不管是不是有意为之。

• position: absolute 的下拉菜单、tooltip、气泡提示，只要 top/left 偏移后超出父盒，就直接消失
• box-shadow、transform: translateX(20px) 或 scale(1.2) 拉伸后的视觉延伸部分全被截断
• 横向滚动区域（比如 overflow-x: auto 的表格）在 Safari 某些版本中会强制显示空白滚动条，且无法隐藏
• 伪元素生成的内容（如 ::before 用 content + margin-left: -20px 拉出的装饰线）也会被裁

overflow: auto 在 iOS Safari 上容易引发滚动卡顿

它比 hidden 安全，只在必要时才出现滚动条，但实际项目中常遇到奇怪表现：轻扫时滚动不跟手、惯性滚动突然中断、或 touchstart 后延迟响应。

MoltOverflow

Moltbots问答社区 - 提问编程问题，分享解决方案

下载

• 这不是 bug，是 WebKit 对 overflow: auto + 浮动混合渲染的优化限制
• 如果父容器内还有 will-change: transform 或频繁重排的动画，卡顿更明显
• 真机调试时容易误判为 JS 性能问题，其实根源在 CSS 渲染层

在 Flex/Grid 容器里加 overflow 属性根本不会触发 BFC

很多人习惯性给父容器写 overflow: hidden，结果发现高度还是塌陷——因为现代布局模式下，浮动本身已被降级处理。

• display: flex 或 display: grid 的父容器，子元素的 float 属性基本失效（Firefox 除外）
• 此时 overflow 不再触发 BFC，也不会影响高度计算；真正起作用的是 flex/grid 自身的布局规则
• 强行加 overflow 只会引入不必要的裁剪风险，毫无收益

和 clear: both 混用是无效且危险的

clear 属性只对「浮动元素之后的兄弟块级元素」生效，对父容器本身完全无意义。

• .parent { clear: both } 是语法错误，浏览器直接忽略，不是兼容性问题
• 如果同时写了 overflow: hidden 和 clear: both，前者生效，后者冗余，还可能干扰 position: absolute 子元素的定位上下文
• 更隐蔽的问题：某些旧版 Chrome 会因这两个声明共存而触发 layout thrashing，尤其在动态插入浮动节点时

真正难排查的，从来不是“为什么清不了浮动”，而是“为什么菜单突然不见了”“为什么阴影一半没了”——这些往往都藏在一行 overflow: hidden 后面。

前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！