空清除浮动是技术债，违反语义、损害可访问性、易失效且现代布局中冗余危险，应改用伪元素或flow-root等纯css方案。
空 <div> <a style="color:#f60; text-decoration:underline;" title="清除浮动" href="https://m.php.cn/zt/72877.html" target="_blank">清除浮动</a>不是“写法错”，而是它把样式问题硬塞进 HTML 结构里，代价远高于收益——尤其在 2026 年的项目中，它已不是权宜之计，而是明确的技术债。
<h3>空 div 违反 HTML 语义，不是“多写一行”，是污染 DOM</h3>
<p><code><div class="clear"></div> 本身无语义，不表达内容、不参与交互、不提供上下文。它只是个“视觉挡板”，却真实存在于 DOM 树中：
- 屏幕阅读器会读出这个空节点，但无法解释用途，损害可访问性
- 搜索引擎无法从中提取信息，白占 DOM 位置，拉低 Lighthouse 可访问性评分
- 构建工具（如 HTML minifier）可能静默移除它，导致清除逻辑突然失效
- JS 查询时，
document.querySelectorAll('.container > div')多出一个干扰项，容易误判子元素数量
clear: both 必须作用在正确位置，否则完全无效
clear: both 不是魔法开关，它只对「块级、且紧邻浮动元素之后的兄弟元素」生效。常见误用直接让清除行为静默失败：
-
.float-box { clear: both; }—— 浮动元素自己设clear，不影响父容器高度 -
.parent { clear: both; }—— 父容器未参与浮动流，声明被浏览器忽略 - 空
<div> 被插在两个浮动元素中间 —— 它只清前面那个，后面仍塌陷 <li>空 <code><div> 被设了 <code>display: none或height: 0且没配overflow: hidden—— 它不占文档流空间，撑不开父容器现代布局下，它既冗余又危险
一旦父容器用了
display: flex或display: grid，子元素的float就失去主布局效力（仅剩文本环绕等边缘行为），此时clear: both完全无效，而空<div> 却还留在 HTML 里，变成技术残留： <ul><li>移动端上，<code><div> 默认有最小高度（约 19px），可能意外引入空白 <li>动态增删浮动元素时，JS 很难可靠同步插入/删除这个空节点，父容器高度忽高忽低</li> <li>伪元素方案（<code>::after）或display: flow-root是纯 CSS 解法，不依赖 DOM 结构，可全局复用
真正麻烦的不是写法本身，而是它掩盖了一个更关键的问题：你还在用 float 做整体布局。2026 年的真实项目里，float 应该只用于图文环绕这类局部场景，主容器布局早该交给 flex 或 grid——那时候，“清除”这个动作，本就不该存在。
