float与现代布局冲突，因其强制脱离文档流，破坏组件封装、父子尺寸联动及语义顺序；在flex/grid中失效却易被误用，仅图文环绕为其不可替代场景。
因为 float 会强制元素脱离文档流，而现代组件化开发依赖可预测的布局上下文、父子尺寸联动和无障碍语义顺序——float 的行为与这三者天然冲突。
float 在 Flex/Grid 容器中直接失效，但开发者常误以为它还在起作用
你给一个 display: flex 的父容器加了 float: left，浏览器会忽略它；同理，float 和 clear 在 display: grid 中被规范明确禁止生效。问题在于：代码里还留着 float: left，开发者却用 justify-content 调对齐，结果发现不对齐——不是属性写错了，而是 float 干扰了 flex 项的初始排列逻辑，尤其在嵌套结构里，bug 难复现也难定位。
- 检查组件样式时，优先看父容器的
display值，若为flex或grid，子元素所有float声明都应立即删除 - React/Vue 组件中通过
className或style注入float，等同于在 TypeScript 里绕过类型系统手动改内存地址——副作用无法被 lint 捕获，运行时才暴露 - CSS-in-JS 方案（如 Emotion）默认启用
no-floatlint 规则，不是为了“限制自由”，而是因为float的渲染影响无法静态分析
父容器高度塌陷不是 bug，而是组件封装失败的信号
组件本该是自包含的 UI 单元，但一旦内部用了 float，父组件就无法正确感知其内容高度——背景色消失、边框包不住、下边距失效，这些都不是样式漏写了，而是组件边界被破坏。更麻烦的是，这种塌陷会向上穿透：一个卡片组件用了 float，嵌进 Grid 布局后，整行高度计算错误，导致相邻卡片错位。
-
display: flow-root可临时兜底，但它只解决塌陷，不解决布局意图；真正该做的是把浮动逻辑从组件内部移除 - 不要在组件根节点上写
overflow: hidden来“撑高”，它会裁剪position: absolute的弹层（比如 Tooltip、Dropdown），移动端尤为明显 - 伪元素清除（
::after { clear: both }）在 Shadow DOM 或 SSR 渲染中可能失效，因为生成的伪节点不一定进入预期渲染上下文
图文环绕是 float 唯一不可替代的场景，但别把它塞进布局主干
纯文本流中的图片左浮/右浮，让段落文字自然环绕，这是 float 的原始设计目标，至今仍是唯一无需 JS、零兼容风险、语义清晰的原生方案。但问题出在：有人把这种局部语义行为，当成全局布局手段——比如用 float: left 实现侧边栏，再用 clear: both 控制主内容区域。这导致 DOM 顺序与视觉顺序倒置，屏幕阅读器先读侧边栏再读正文，违反 WCAG 顺序一致性原则。
- 侧边栏 + 主内容这类结构，应使用
display: grid的grid-template-areas或display: flex的order控制逻辑顺序 - 如果必须保留图文环绕，确保它只出现在
<p></p>、<article></article>等流式内容容器内，且父容器未设置display: flex/grid - 现代替代：需要更精细绕排（如椭圆、多边形）时，
shape-outside比float更可控，但仅限现代浏览器
真正难的不是怎么清除浮动，而是当组件 props 动态改变高度、响应式断点频繁切换、或与其他团队共享 UI 库时，float 带来的隐式依赖会让你根本不知道该从哪开始 debug。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
