现代项目首选 display: flow-root 清除浮动，它创建独立 bfc 且无副作用；fallback 可用 ::after 伪元素方案，需确保 content、display、clear 三要素齐全；避免滥用额外 div 或 overflow: hidden 等反模式。
因为清除浮动是样式逻辑，不是结构语义，硬塞一个 <div class="clear"></div> 会污染 DOM、破坏可维护性，且在动态场景下极易失效。
为什么额外添加 <div class="clear"> 是反模式
<p>它把本该由 CSS 承担的布局修复责任，强行推给了 HTML 结构。</p>
<ul><li>每次增删浮动子元素，都必须同步检查并手动维护这个空 <code><div> 是否存在——漏删或忘加，父容器立刻塌陷
<li>DOM 节点数无谓增加，React/Vue 等框架中还可能干扰 key 机制或 diff 判断</li>
<li>移动端某些旧浏览器（如 Android 4.x WebView）对空 <code><div> 默认渲染最小高度（约 19px），导致意外留白
<li>语义上毫无意义：<code><div class="clear"> 既不表示内容，也不承载交互，纯属“为 CSS 跑腿”的冗余标签
<h3>
<code>overflow: hidden 看似简洁，但副作用太隐蔽
它确实能触发 BFC 让父容器撑开，但代价是牺牲了设计自由度。
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 哪怕内容没溢出，Safari 某些版本仍会渲染空白滚动条（尤其配合
transform或will-change时） - 一旦后续需求要求子元素横向溢出（比如轮播图、长表格），
overflow: hidden会让内容直接被裁掉，且难以定位问题源头 - 和
position: fixed子元素共存时，fixed 元素可能脱离视口定位，变成 relative 行为（Firefox 早期版本典型表现） - 它和
float本身没有逻辑关联，只是“碰巧”借用了 BFC 的副作用——属于典型的治标不治本
现代项目首选 display: flow-root，但要注意继承重置
这是 CSS Display Module Level 3 标准属性，一行代码创建独立 BFC，无伪元素、无 zoom、无兼容补丁。
- 写法极简：
.container { display: flow-root; }，父容器自动包裹所有浮动子元素 - 不触发溢出裁剪，不影响
position: fixed定位，也没有overflow带来的滚动条干扰 - 注意：
flow-root会重置部分继承链，比如font-size不再从父级继承（而是从根元素继承），老项目中可能让文字突然变小 - 兼容性已足够宽：Chrome 64+、Firefox 59+、Safari 15.4+、Edge 79+；IE 完全不支持，需确认项目是否还需兼容 IE
::after 伪元素方案仍需保留，但别照抄老式写法
它仍是目前最通用的兜底方案，尤其要兼容 IE8–IE11 或需要精确控制渲染时机时。
- 核心三要素不能少：
content: ""（缺则伪元素不渲染）、display: block（确保参与流式布局）、clear: both（打断浮动流） -
visibility: hidden和height: 0可选，但line-height: 0更稳妥——避免某些字体下伪元素仍占行高 - IE6–IE7 必须加
zoom: 1触发 hasLayout，但现代项目若已放弃 IE 支持，这行可安全删除 - 别把 clearfix 当万能类滥用：只在真正含浮动子元素的容器上加，否则多余生成伪元素，徒增渲染负担
真正容易被忽略的是：清除浮动从来不是“加个样式就完事”，而是要判断「这个容器是否真的需要容纳浮动」——很多时候，用 display: flex 或 display: grid 替代 float 才是更彻底的解法。但若 legacy 代码里 float 已深埋，那就得选对清除方式，而不是随便挑一个能“看起来正常”的。
