clear: both 并非清除浮动，而是让当前元素上边框避开前一个同级浮动兄弟元素的外边缘，仅在同一父容器下对紧邻块级兄弟生效；父容器外部或非兄弟关系的浮动元素对其无效。
clear: both 本来就不处理“父容器外部”的浮动
clear: both 不是“清除浮动”这个动作，而是让**当前元素的上边框避开前一个同级浮动兄弟元素的外边缘**。它只在文档流中向后看一个位置，且必须是同一父容器下的紧邻块级兄弟。父容器外部的浮动元素，对它来说根本不存在——既不是“前一个兄弟”，也不在同一个格式化上下文中。
为什么检查 DOM 结构比查 CSS 更快定位问题
常见误判是：看到视觉上某个浮动块在左边、另一个在右边，就以为它们“相邻”，该用 clear: both 去隔开。但实际 DOM 中可能长这样：
<div class="sidebar"> <div class="float-left"></div> </div> <div class="main"> <div class="content"></div> </div>
此时 .content 和 .float-left 不是兄弟关系，中间隔着两层父容器。clear: both 加在 .content 上毫无意义。
实操建议：
- 用开发者工具右键 → “Reveal in Elements panel”，确认两个元素是否真在同一个
<div> 下，且后者在 HTML 源码中紧接前者之后<li>检查中间有没有 <code><!-- comment -->、空文本节点、display: contents包裹层——这些都会打断“紧邻”关系 - 若结构无法调整（比如 CMS 输出固定嵌套），别硬塞 clear，改用
display: flow-root或 Flex/Grid 重构局部布局 - 浮动元素的父容器是否用了
display: flex/display: grid？如果是，clear 无效是预期行为，不是 bug - 浮动元素是否被
transform或will-change触发了层叠上下文？这不会影响 clear，但常伴随布局错乱，容易混淆归因 - 目标 clear 元素自身是否被设为
display: inline、display: inline-flex或display: contents？Computed 面板里display值不是block、table、flow-root等，clear 就不启动
浮动元素脱离文档流后，clear 就失去参照物
一旦浮动元素被包裹在 display: flex 或 display: grid 容器里，它的 float 属性本身就被浏览器忽略（Firefox 除外），更不用说让其他元素去“避开”它。同理，position: absolute 或 position: fixed 的元素也已脱离文档流，clear: both 对它们视而不见。
关键判断点：
真正要解决的往往不是“清除”，而是“重新包含”
你加 clear: both，八成其实是想让某个容器能包住内部浮动子项（即解决高度塌陷）。但 clear 本身做不到这点——它只推下一个元素，不改变父容器的布局计算逻辑。父容器依然“看不见”浮动子项的高度。
现代标准解法是直接给父容器设 display: flow-root。它创建一个无副作用的 BFC，自动包含所有浮动子项，无需伪元素、空 div 或 overflow 裁剪。兼容性已覆盖 Chrome 64+、Firefox 59+、Safari 15.4+、Edge 79+。
容易被忽略的一点：display: flow-root 是 CSS Level 3 的正式属性，不是 polyfill 或 hack；它不依赖 HTML 结构，也不受兄弟元素影响，只要写在浮动容器上，就生效。
