浮动元素脱离文档流导致后续块级元素无视其存在，margin失效；触发BFC（如overflow:hidden）是根治方案，clear:both仅适用于单点修复，现代布局应优先使用Flex或Grid。
为什么浮动后后面的元素margin不生效
因为浮动元素脱离了普通文档流，后续块级元素会“无视”它的存在，直接从父容器顶部开始布局，看起来就像 margin 被吞了一样。这不是 bug，是 CSS 浮动的原始设计行为。
常见错误现象：margin-top 或 margin-bottom 在浮动元素后面完全没反应，尤其在列表项、图文混排、侧边栏+主内容布局里高频出现。
- 不是 margin 写错了，也不是单位问题，而是元素根本没“感知”到浮动块的存在
- 如果父容器没设高，还会连带导致高度塌陷，进一步影响后续布局
-
clear: both只能解决紧邻元素的问题，对更远的兄弟元素无效
用 overflow: hidden 触发 BFC 是最稳的方案
BFC（块级格式化上下文）能让容器重新计算内部浮动的影响范围，从而让 margin 恢复作用。给浮动元素的父容器加 overflow: hidden（或 auto、scroll）是最轻量、兼容性最好（IE7+）的做法。
使用场景：你控制的是父容器样式，且不依赖溢出内容可见（比如卡片、导航栏、文章正文区）。
立即学习“前端免费学习笔记（深入）”；
-
overflow: hidden会裁剪溢出内容，若父容器内有下拉菜单、tooltip 等需外溢的元素，要改用overflow: auto - 不要对
html或body直接设overflow: hidden，会导致全局滚动失效 - Flex 或 Grid 容器天然形成 BFC，但如果你还在用 float 布局，就别指望它们自动帮你兜底
/* 示例：修复浮动图片后的段落 margin */
.article {
overflow: hidden; /* 关键 */
}
.article img {
float: left;
margin-right: 12px;
}
.article p {
margin-top: 16px; /* 这次能正常显示了 */
}clear: both 只适合单点修复，别滥用
clear: both 的作用是“让当前元素下移，直到避开所有浮动”，它不改变父容器行为，只调整自身位置。适合修复某个特定元素的错位，不适合通杀整个布局。
容易踩的坑：
- 给每个后续元素都加
clear: both，代码冗余且难以维护 - 在 flex 容器子项上写
clear—— 完全无效，flex 项目不参与浮动流 -
clear对 inline 元素无效，必须是块级或 table 类型 - IE6/7 中
clear在某些 display 类型下表现异常，优先选 BFC 方案
现代替代方案：别再用 float 做布局了
float 本意是文字环绕图片，不是做三栏布局的。现在用 display: flex 或 display: grid 替代，margin 失效问题自然消失，语义和维护性也强得多。
但现实是：老项目、CMS 模板、邮件 HTML 还大量依赖 float。所以得会修，也得知道什么时候该重构。
- 邮件中仍需 float（因 Outlook 等客户端对 flex 支持极差），此时必须用 BFC 或
clear - 用
float: right实现右对齐按钮？改用text-align: right或margin-left: auto（flex 下）更干净 - 检查是否真需要 float —— 很多所谓“清除浮动”的需求，其实只是没写对 HTML 结构或漏了 BFC 触发条件
浮动本身不复杂，难的是判断“该清谁的浮”“清完会不会影响别的地方”。BFC 是根治逻辑，clear 是止血绷带，而换掉 float 才是彻底不用包扎。
