浮动导致父容器高度塌陷是CSS规范设计而非bug，清除浮动只是弥补文档流断裂；混用清除方案、响应式重写及与Flex/Grid冲突均使其维护成本远高于直接使用现代布局。
浮动导致父容器高度塌陷是必然行为，不是bug
给子元素加 float: left 后父容器高度变成 0，这不是你漏写了 clear，而是 CSS 规范明确规定的：浮动元素脱离普通文档流，父容器自然无法感知其尺寸。这种“看不见”是模型层面的设计，清除浮动（如 .clearfix::after）只是用 hack 弥补这个断裂，而非修复逻辑本身。
清除浮动的方案越多，后期越难维护
真实项目里，清除策略往往混用，结果互相干扰：
-
overflow: hidden看似简单，但会裁剪position: absolute子元素或box-shadow溢出部分 -
display: flow-root更干净，但 IE 不支持，若需兼容旧政企系统就得 fallback 到其他方式 - 伪元素
::after清除需要每个浮动父容器都加类，一旦漏掉一个，塌陷就重现；更麻烦的是，它和flex或grid容器共存时直接失效——现代布局引擎根本不处理float的清除逻辑
响应式场景下，清除逻辑必须跟着断点重写
比如 PC 端两栏用 float，移动端要改成单列，你以为只加个 @media (max-width: 768px) { .col { float: none; } } 就完事？错。你还得同步处理：
- 原
clear: both在小屏下可能让内容强制换行，破坏视觉流 - 浮动时依赖的
width和margin值在小屏下未必适用，不重置就会堆叠错位 - 如果用了
overflow: hidden清除，小屏下可能因内容变长而意外裁剪
和 Flex/Grid 混用时，clear 直接失效，连调试线索都没有
只要父容器设了 display: flex 或 display: grid，子元素的 float 就被忽略，clear 也失去作用对象。此时你看到的“没清除成功”，其实是因为布局引擎压根没进入浮动计算路径。检查工具里看不到报错，控制台也不提示，只能靠经验意识到：“哦，这里不该有 float”。这种隐性冲突比显性报错更耗时间。
立即学习“前端免费学习笔记（深入）”；
真正难的不是写清楚除代码，而是每次加新模块、改旧样式、切响应式断点时，都要重新判断：这个容器是否还受浮动影响？它的清除方式是否仍有效？有没有被上层 flex 容器静默接管？这些判断成本，远高于一开始用 display: flex 写清楚对齐和换行。
