浮动布局混乱主因是html结构与clear位置不匹配：clear只对紧邻前一个浮动块生效，且仅作用于块级元素；父容器触发bfc时clear可能被绕过；clearfix须加在直接包裹浮动子项的容器上，display: flow-root更优。
浮动导致排版混乱，八成不是CSS写错了，而是HTML结构和clear位置没对上——clear只对“紧挨着的前一个浮动块”起作用，插错地方反而让布局更乱。
clear: both为什么加了也没用
常见现象是：加了clear: both，但后续内容还是钻到浮动块底下，或者整行被顶到下一页。这不是浏览器bug，而是clear的生效逻辑被忽略了：
- clear只作用于「块级元素」，如果目标元素是
display: inline、display: flex或position: absolute，它直接失效 - clear必须紧跟在浮动元素之后，中间不能隔着其他非浮动块级元素（比如一个
<p></p>或<div>没设float） <li>如果父容器已触发BFC（如<code>overflow: hidden），clear可能被绕过——此时它不是没生效，而是没必要生效 - 如果
<div class="right">写在<code><div class="left">前面，又都设<code>float: right和float: left，浏览器会按源顺序先处理右侧块，再处理左侧块，极易造成上下错位 - 父容器也设了
float？那整个结构都脱离文档流，子元素的相对位置更不可控 - 检查是否有隐藏的空白文本节点（比如换行、缩进），它们在inline上下文中会占位，干扰浮动项的水平排列
- 例如
.sidebar > .tag-list > .tag，其中.tag浮动，那么.tag-list需要clearfix；如果.sidebar本身也浮动，它也需要自己的clearfix或display: flow-root - 全局统一加
.clearfix类？容易漏掉内层，也容易多加——给已经用display: flex的容器再加，完全多余 - 用
display: flow-root替代clearfix更省心：.tag-list { display: flow-root; }一行搞定，不依赖伪元素，也不吃额外高度 - 只在屏幕样式里写了
clear: both，但打印媒体查询里没重写，导致浮动照常生效，而打印引擎根本不处理float - 响应式断点中把父容器
overflow从hidden改成了visible（比如为了让下拉菜单显示），结果高度塌陷立刻重现 - 子项用了
width: 25%，但没在媒体查询里同步重置margin和border，calc()算出来的宽度在小屏下差1px，整行就换行错位
浮动元素顺序错乱时，先看HTML里谁在前谁在后
浮动元素视觉顺序和HTML源顺序不一致，根本原因是它们脱离了文档流。但很多人忘了：HTML结构本身就在决定“谁先浮、谁后浮”。
clearfix该加在哪个容器上
不是“所有父级都加.clearfix就保险”，而是必须加在「直接包裹浮动子项的那个容器」上。嵌套浮动时，每一层都要单独处理：
打印或响应式断点里最容易忽略的点
PC端看着好好的浮动布局，一进@media print或@media (max-width: 768px)就全乱，往往是因为：
真正难处理的不是怎么加clear，而是浮动让布局失去可预测性——哪怕只有一处浮动没被正确收口，后续所有断页、背景、边框、甚至JS获取的offsetHeight都会出偏差。
