浮动元素边界需用outline显式描边才能准确定位，因其脱离文档流导致父容器塌陷、清除失效及IE hasLayout异常等问题，仅靠float属性值无法判断实际布局位置。
浮动元素看不见边界？用开发者工具显式描边
Chrome/Firefox 的开发者工具默认不显示 float 元素的边界框，你以为它“贴着左边”，其实可能被父容器 padding 挤偏了，或者被上一个兄弟元素的清除行为截断。直接看渲染结果容易误判，必须强制让边界可见。
- 右键浮动元素 → “检查” → 在 Styles 面板中手动添加临时样式：
outline: 1px solid red;（比border更安全，不影响盒模型） - 不要依赖“Computed”面板里的
float值为left就认定它真正在左——得看它实际占位是否和预期一致 - 如果加了
outline后发现元素位置突变，大概率是触发了 BFC 或改变了行内格式化上下文，说明原始布局已处于脆弱状态
父容器塌陷时，浮动边界“消失”的真实原因
所谓“浮动元素脱离文档流”，不是它没了边界，而是父容器在计算高度时直接忽略它。这时候你在开发者工具里选中父容器，看到的 height 可能是 0 或远小于预期，但浮动子元素的 outline 依然能画出来——只是它浮在父容器视觉范围之外。
- 验证方法：在父容器上临时加
border: 1px solid blue;，再给浮动子元素加outline，立刻能看出子元素是否“飘出”父容器边界 - 常见误操作：只给父容器加
overflow: hidden;就以为修好了，但没意识到这其实是创建了 BFC，本质是靠新格式化上下文把浮动“兜住”，不是修复浮动本身 - 兼容性注意：
display: flow-root;是更干净的替代方案，但 IE 完全不支持，若需兼容就得回退到overflow或伪元素清除法
清除浮动后布局错乱？重点查 clear 的作用对象
clear 不是“把前面的浮动收掉”，而是“让当前元素的上边界避开指定方向上的浮动元素”。如果清除失败，往往是因为目标浮动元素不在它的**正常文档流前驱位置**——比如中间插了绝对定位元素、或被 display: none 暂时隐藏但 DOM 还在。
- 在 Elements 面板中，逐个展开兄弟节点，确认
clear: both;元素上方**最近的、未被隐藏的、参与文档流的浮动元素**是否存在 - 用开发者工具的“Layout”侧边栏（Chrome）或“Box Model”（Firefox），查看该元素的
clear计算值是否为none——有时 CSS 优先级被覆盖，表面写了clear实际没生效 - 避免用
clear: both;粗暴清所有浮动，尤其当页面存在多组独立浮动区域时，会导致后续内容被不必要地往下顶
IE8–IE11 下浮动边界错位，hasLayout 是关键线索
老 IE 的浮动 bug 很多不是 CSS 写错了，而是触发 hasLayout 的方式不对。比如给浮动元素设 zoom: 1; 能修复部分错位，但加在父容器上却无效——因为 hasLayout 必须作用于浮动元素自身或其直接容器才稳定。
立即学习“前端免费学习笔记（深入）”；
- 在 IE 开发者工具（F12）中，看“Style”面板底部是否显示
hasLayout = true；若为false，即使写了float，渲染也可能异常 - 触发方式优先级：设置
width/height>zoom: 1;>position: relative;；但min-height: 0;在 IE 中无效，别白试 - 现代调试时容易忽略这点：用 Chrome 看没问题，切到 IE 模拟器才发现浮动块右边缘参差不齐——那八成是某个容器缺少
hasLayout触发条件
float 值有用得多。 
