浮动元素设width:100%不会自动换行，而是强行占满当前行可用内容宽度；其100%参照包含块（如视口或最近定位上下文）计算，非父容器，且因脱离文档流导致父容器高度塌陷、宽度计算失准、横向溢出。
浮动元素设 width: 100% 不会“自动换行”，它只会强行占满当前行的可用内容宽度，而所谓“掉落”其实是总宽度超限后被浏览器硬挤到下一行——这是浮动机制的确定性行为，不是渲染 bug。
浮动元素的 100% 宽度参照谁计算？
它不参照你写的父容器，而是参照「包含块」（containing block），通常是视口或最近的定位上下文。一旦元素 float: left，就脱离文档流，父容器高度塌陷为 0；此时 width: 100% 实际按 0 计算，浏览器虽常 fallback 到视口宽度，但不可靠，尤其在 display: flex 或 display: grid 父容器中直接失效。
常见错误现象：ul 里多个 li 都设了 float: left; width: 100%，结果全部堆在同一行、横向滚动条悄悄出现，DevTools 里看 computed width 却显示 “100%”——那只是伪值，真实渲染已失控。
为什么加了 overflow: hidden 还是掉？
overflow: hidden 是为了触发 BFC，让父容器重新包裹浮动子元素的高度，但它不改变浮动元素自身的尺寸计算逻辑。真正起作用的是：
- 父容器显式设
width（比如width: 100%或固定值） - 浮动子项同步用
max-width: 100%，而非仅width: 100% - 若父容器是
width: auto，max-width: 100%就无从参考，必须补上width: 100%或inline-size: 100%
盒模型开销才是掉队的真正推手
浮动元素的总占用宽度 = width + padding + border + margin。很多人只盯着 width 设值，结果在窄容器里溢出、触发换行或滚动条。
- 父容器设了
padding: 16px，它的 content 宽度就比总宽少 32px；子元素width: 100%只能拿到这个缩水后的值 - 子元素自己再加
padding: 8px和border: 1px，实际占宽 = content 宽 + 16px + 2px → 必然超 - HTML 源码中两个浮动
<div> 之间如果有换行或空格，会被解析为一个空格字符，造成约 4px 的意外间隙<li> <code>* { box-sizing: border-box }是必须的，但它只管住子元素自身，对父容器的padding和border无能为力 -
float: none：强制退出浮动状态，这是前提 -
width: 100%：避免width: auto导致内容收缩或撑开 -
margin-right: 0（或完整重置margin）：清除原浮动带来的外边距残留
响应式断点里只写 clear: both 为什么没用？
clear: both 不是“取消浮动”，而是让当前元素避开上方已浮动的兄弟——它不改变浮动元素自身脱离文档流的状态。小屏下错位根源是 float 仍在生效，父容器高度依然塌陷。
要让浮动元素在小屏下真正回归垂直堆叠，必须三者同步改：
更关键的是：断点必须用 @media (min-width: 768px)，而不是 max-width。移动端优先要求默认小屏样式（块状堆叠），再用 min-width 增强为并排；否则设备视口恰好 768px（如 iPad 竖屏）时规则完全不生效，两栏直接挤成一行还溢出。
浮动布局的“掉队”本质是一连串隐性条件叠加的结果：脱离文档流 → 父容器高度坍缩 → 包含块错位 → 宽度计算失准。修复不能只靠补丁，得看清目标：是临时兜底？兼容老项目？还是为长期演进铺路？现代项目中，display: flex 或 display: grid 才是真正可控的解法。
