clear不是万能清浮动开关，它只对浮动元素的后续兄弟元素生效，对自身、父容器或非块级元素无效；滥用会破坏文档流、触发margin折叠，掩盖bfc问题。
clear 不是万能的“清浮动开关”，它只解决特定位置的布局干扰，滥用反而会破坏文档流、触发意外 margin 折叠、或掩盖真正的 BFC 问题。
clear: both 加在浮动元素自己身上完全无效
很多人给浮动子元素写 float: left; clear: both，以为这样就能“清理自己”。其实 clear 对浮动元素自身不起作用——它已脱离文档流，clear 的计算逻辑不适用。这个写法既不能撑开父容器，也不能影响其他兄弟元素，纯属冗余。
- 浮动元素设
clear，只可能让它避开前面的浮动兄弟（比如两个左浮元素之间加clear: both，第二个会被推到下一行），但对父容器高度零贡献 - 如果父容器里只有浮动子项，没加任何非浮动兄弟节点，那
clear根本无处可施 - 检查 computed styles，确认目标元素实际是块级（
display: block或table等），inline或flex子项上设clear会被忽略
父容器上写 clear: both 是语法错误
clear 属性只对「自身所在的块级盒」生效，且必须是浮动元素的**后续兄弟元素**。父容器和浮动子项是祖先–后代关系，不是兄弟关系，所以浏览器直接忽略 .parent { clear: both } 这类声明。
如果你了解HTML，CSS和JavaScript，您已经拥有所需的工具开发Android应用程序。本动手本书展示了如何使用这些开源web标准设计和建造，可适应任何Android设备的应用程序 - 无需使用Java。您将学习如何创建一个在您选择的平台的Android友好的网络应用程序，然后转换与自由PhoneGap框架到一个原生的Android应用程序。了解为什么设备无关的移动应用是未来的潮流，并开始构建应用程序，提供更
- 这个规则在 CSS 规范里明确不生效，不是兼容性问题，而是语义错误
- 即使你看到某些旧项目里这么写且“好像有用”，大概率是巧合：比如父容器同时设置了
overflow: hidden，真正起作用的是后者触发的 BFC - 调试时若发现父容器塌陷，第一反应不该是“加 clear”，而应检查是否触发了 BFC（如
display: flow-root、overflow: hidden、或伪元素::after）
用 overflow: hidden 替代 clear 会静默裁剪内容
虽然 overflow: hidden 能触发 BFC、让父容器包住浮动子项，但它副作用实在：所有溢出部分都会被裁掉——包括 position: absolute 下拉菜单、box-shadow、transform 位移后的内容，全都不可见。
- 这不是 bug，是规范行为；但很多开发者直到上线才发现弹窗被截半、阴影消失
- 和
clear: both混用是冗余的：overflow: hidden已闭合 BFC，clear对父容器无效，还可能干扰absolute子元素的定位上下文 - 现代项目优先用
display: flow-root，它同样触发 BFC，但无裁剪副作用；IE11 不支持是唯一硬伤
Flex/Grid 布局中加 clearfix 是无效劳动
一旦父容器设为 display: flex 或 display: grid，子元素的 float 属性基本被忽略（Firefox 除外），它们自动成为 flex item 或 grid item，不再脱离文档流，父容器自然能正确计算高度。
-
.clearfix类加在 flex 容器上，伪元素::after仍会渲染，但因父容器已是 BFC，它不参与高度撑开，纯属多此一举 - 混用 float 和 flex 很危险：比如父容器
display: flex，但某个子项又写了float: left，结果不可预测，且clear无法修复这种混乱 - 真正要检查的不是“有没有 clear”，而是“这个容器到底用的是什么布局模式”——查 computed styles 中的
display值最靠谱
最容易被忽略的点是：清除浮动的本质，从来不是“让浮动消失”，而是“让父容器承认浮动子项还在文档流里”。所以判断标准永远是父容器的渲染高度，而不是子元素飘没飘走。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
