不推荐用 float 做响应式分栏——因其本质是图文环绕而非布局工具
用 float 来实现响应式分栏？这个想法听起来很直接，但实践起来，往往是麻烦的开始。它能勉强跑通，却会在现代设备和复杂的嵌套结构里，埋下无数个需要排查的坑。
为什么 float 在响应式场景下容易出问题
问题的根源在于，float 属性生来就不是为了布局。它的设计初衷是解决图文环绕，这就决定了它在布局任务上存在先天不足。最典型的副作用就是导致父容器“塌陷”——如果不手动清除浮动（比如添加经典的 .clearfix:after 或设置 overflow: hidden），父元素的高度就会丢失，随之而来的是背景不显示、后续元素位置错乱等一系列连锁反应。
而在响应式设计中，当媒体查询反复切换元素的 float: left 或 float: none 状态时，很容易触发浏览器的重排抖动，页面性能会受到影响，尤其是在 iOS Safari 上，表现可能更不稳定。
- 在移动端竖屏布局时，
float: left和float: right的属性依然会驱使元素横向争夺空间，这常常导致内容被意外截断或出现异常的换行。 - 它缺乏原生的“换行控制”机制。一旦
clear: both的位置设置不当，下一栏就可能被卡在上一栏的末尾，布局瞬间混乱。 - 由于
float元素会脱离正常的文档流，一系列我们习以为常的规则会随之失效，例如margin合并、vertical-align对齐。更棘手的是，如果在 Flexbox 或 Grid 布局的子项中混用float，后者会直接失去作用。
如果非要用 float，至少守住这三条底线
当然，现实情况是，在维护一些老项目或者需要兼容 IE8–9 等旧环境时，可能仍然避不开 float。如果必须使用，那么请务必遵循以下三条底线规则，以将风险降到最低：
- 明确宽度：所有浮动元素必须设置明确的宽度（例如
width: 30%），绝不能依赖auto。否则，在不同视口尺寸下，其布局行为将变得不可预测。 - 强制清除：父容器必须应用可靠的
.clearfix类。一个健壮的清除方案通常需要包含display: table或针对 IE 的zoom: 1，并结合:after伪元素。仅仅依赖overflow: hidden在某些安卓 WebView 中可能导致子元素被意外裁剪。 - 同步重置：在媒体查询中修改
float属性时，必须同步重置width和clear属性。例如：@media (max-width: 768px) { .left { float: none; width: 100%; clear: both; } }
float + 媒体查询的典型错误写法
常见的翻车案例，往往集中在“只调整浮动状态，却忘了同步修改宽度”或者“忘记清除浮动”这两个环节。来看一个对比：
立即学习“前端免费学习笔记（深入）”；
.sidebar {
float: right;
width: 25%;
}
.main {
float: left;
width: 75%;
}
/* 错误示范：下面这段只取消了浮动，没设宽度，也没清浮动，移动端布局会直接叠在一起 */
@media (max-width: 600px) {
.sidebar, .main {
float: none;
}
}
/* 正确补丁 */
@media (max-width: 600px) {
.sidebar, .main {
float: none;
width: 100%;
clear: both;
}
.container {
overflow: hidden; /* 或插入 .clearfix 类 */
}
}
然而，真正棘手的往往不是这些基础的写法。当页面中混入了 position: absolute、transform 或者现代框架的组件（例如 Vue 的 v-if 动态切换）时，float 潜藏的副作用可能会在某个意想不到的时刻突然爆发。比如，某天突然发现侧边栏在 iPad 上消失了，排查许久才发现，原因竟是某个第三方弹窗的 Ja vaScript 动态给 body 添加了 overflow: hidden，意外地把浮动容器也给裁剪掉了。这种难以追溯的交互问题，才是 float 布局在复杂项目中最大的隐患。
