clear: both 只对块级元素生效，因其作用机制是在块级格式化上下文中强制元素下移避开浮动区域；行内元素、inline-block 或 flex 子项不参与块级流，故忽略该属性。
clear: both 为什么只对块级元素生效
因为 clear 的作用机制是「强制元素下移，避开指定方向的浮动区域」，这个行为只在块级格式化上下文中被定义和执行。行内元素、display: inline-block 或 display: flex 子项不参与块级流排布，自然忽略 clear。
常见错误现象：<p style="clear: both"></p> 生效，但 <span style="clear: both"></span> 完全没反应；或者给 Flex 容器里的子元素加 clear，结果布局毫无变化。
适用场景：侧边栏 float: left 后，主内容区需要完整换行、不环绕、不被遮盖——此时给主内容区容器（如 <main></main>）加 clear: both 最直接。
注意点：
立即学习“前端免费学习笔记（深入）”；
-
clear必须写在「浮动元素之后」的兄弟元素上，写在浮动元素自身上只会禁用其对应方向的浮动能力（比如float: left; clear: left= 不浮动） - 如果兄弟元素是
display: inline或display: table-cell，需先改成block或inline-block才能响应 - 响应式断点里，
clear可能因媒体查询切换而失效，建议配合类名控制而非内联样式
浮动元素总宽度超限导致换行错乱
两个 float: left 的 <div> 并排时，哪怕只多出 1px，浏览器就会把第二个挤到下一行——这不是 bug，是规范行为：浮动元素必须「完全容纳在父容器行框内」。<p>典型诱因：</p>
<ul>
<li>未设 <code>box-sizing: border-box，width: 50% + padding: 10px 实际占宽 > 50%
font-size: 16px 下），让两个 50% 元素无法并排padding 或 border，但子元素宽度按 100% 计算，未减去这些值实操建议：
- 统一加
*, *::before, *::after { box-sizing: border-box; } - 浮动元素写成紧凑 HTML：
<div></div> <div></div>，不要换行或空格 - 用
calc(50% - 10px)显式预留间隙，比依赖 margin 更可控
overflow: hidden 能“清浮动”但会裁剪溢出内容
它真正做的是触发 BFC，让父容器包含内部浮动子元素，从而撑高自身高度——看起来像清了浮动，其实是绕开了塌陷问题。
性能与兼容性影响：
- 旧版 Android WebView（≤ Android 4.4）中，
overflow: hidden可能引发合成层爆炸，滚动卡顿 -
overflow: auto更安全，但可能意外出现滚动条（尤其在缩放或动态内容插入后） - 现代项目可用
overflow: clip（Chrome 111+、Firefox 119+），无滚动条、不触发合成、不裁剪绝对定位子元素
关键限制：
- 对
<table> 自身设 <code>overflow无效，必须作用于包裹它的<div> <li>如果页面有 tooltip、下拉菜单、弹窗等绝对定位内容，且超出父容器边界，<code>hidden会让它们不可见
现代项目该用 display: flow-root 还是 clearfix
display: flow-root 是 W3C 标准方案，语义清晰、无副作用、不依赖伪元素，Chrome 64+/Firefox 58+ 全面支持。它本质就是创建一个 BFC 容器，且明确告诉浏览器「我就是用来包裹浮动的」。
而 .clearfix::after 是历史兼容方案，核心就三行：
.clearfix::after {
content: "";
display: table;
clear: both;
}容易踩的坑：
-
content: ""缺失 → 伪元素不渲染 → 清浮动失败 - 用
display: block替代display: table在 IE8/9 下可能引发 margin 折叠异常 - 若父容器本身是
display: flex或display: grid，再加clearfix完全多余——float在这类容器中本就不生效
真实陷阱常出现在渐进式迁移中：部分组件仍用 float 布局，外层已切 grid，结果 float 被忽略，但开发者还在 debug clearfix 为何不工作。
