浮动元素设 width: 100% 不会填满一行，因其参照包含块而非父容器计算宽度，且脱离文档流导致父容器高度塌陷、宽度计算失准、横向溢出。
浮动元素设 width: 100% 不会“填满一行”，而是大概率触发横向溢出、父容器高度塌陷、换行失效——这不是 bug，是浮动机制与盒模型叠加后的必然结果。
浮动元素的 100% 参照谁计算？
它不参照你写的父容器，而是参照「包含块」（containing block），通常是视口或最近的定位上下文。一旦元素 float: left，就脱离文档流，父容器高度坍缩为 0；此时 width: 100% 实际算的是 0px，浏览器虽常 fallback 到视口宽度，但行为不可靠，尤其在 display: flex 或 display: grid 父容器中直接失效。
常见错误现象：ul 里多个 li 都设了 float: left; width: 100%，结果全部堆在同一行、横向滚动条悄悄出现，DevTools 里看 computed width 却显示 “100%”——那只是伪值，真实渲染已失控。
父容器 padding/border 会让 width: 100% 溢出
width: 100% 只取父容器的 content box 宽度，完全忽略其 padding 和 border。比如父容器设了 padding: 16px，content 宽度就比总宽少 32px；子元素再加 padding: 8px 和 border: 1px，实际占宽 = content 宽 + 16px + 2px → 必然超限。
-
* { box-sizing: border-box }是必须的，但它只管住子元素自身，对父容器的padding无能为力 - 临时调试时给父容器加
outline: 1px solid red，一眼看出子元素是否“凸出来” - 若父容器必须留白，别用
padding，改用margin（不影响子元素 width 计算）或嵌套一层内层容器
clear 才是控制“换行”的真正手段
浮动本身没有换行逻辑。width: 100% 不会让第 4 个卡片自动掉到下一行——它只会强行占满当前行可用 content 宽度，然后溢出。所谓“换行”，本质是用 clear: left 强制跳过上方所有左浮动元素，寻找新的水平起始位置。
容易踩的坑：
- 在父容器末尾加空
div并设clear: both：这是冗余操作，不解决高度塌陷，还多一个 DOM 节点 -
clear: both放在子元素上（如最后一个浮动项），只影响它自己下方布局，对父容器高度零作用 - 想让网格卡片响应式换行？
width: 33.333%+ 浮动 + 四舍五入误差 → 最后一项可能掉行且位置不可预测
为什么 overflow: hidden 也救不了 width: 100%
加 overflow: hidden 是为了触发 BFC，让父容器重新包裹浮动子项高度，但它不改变浮动元素自身的尺寸计算逻辑。常见误判：以为这样就能让 max-width: 100% 生效，结果图片还是冲出卡片边界——因为浮动图片的包含块没变，max-width: 100% 依然按视口宽算。
真正起作用的是：
- 父容器显式设
width: 100%（或固定值），再配合浮动子项的max-width: 100% - 用
display: flow-root替代overflow: hidden，避免意外裁剪 - 检查子元素是否为内联元素（如
span）：即使加了float，原始display类型仍影响尺寸计算，必须显式设display: block
浮动不是响应式布局的合理解法，它的失效往往是一连串隐性条件叠加的结果：脱离文档流 → 父容器高度坍缩 → 包含块错位 → 宽度计算失准 → 盒模型溢出暴露。修复时得一层层往回捋，而不是只调一个 width。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
