行，overflow: hidden能触发BFC使右侧内容自适应，但易因截断、兼容性或未清浮动出问题；推荐用display: flow-root，语义明确、无副作用、兼容现代浏览器。
float图片后右侧内容不设width却要自适应，靠overflow: hidden行不行？
行，但得理解它为什么能“撑开”——overflow: hidden在这里不是为了隐藏溢出，而是触发BFC（块级格式化上下文），让右侧元素无视浮动、自动收缩到浮动元素剩余空间内。
常见错误是只加overflow: hidden却不处理父容器或内部流式行为，结果内容被截断、换行异常，或者在Flex/Grid时代误用还卡在老套路里。
- 必须确保右侧元素是块级（比如
<div>），且没有float、position: absolute等脱离文档流的设置 - 父容器不能有
zoom: 1或hasLayout类IE hack，现代浏览器只认BFC触发条件 - 如果右侧内容里有
white-space: nowrap或长单词（如URL），overflow: hidden真会把内容切掉——这不是“自适应”，是“硬裁剪”
替代方案：display: flow-root比overflow: hidden更干净
display: flow-root是专为解决这个问题设计的CSS属性，语义明确、副作用为零，兼容性也够用（Chrome 64+/Firefox 59+/Edge 79+）。
相比overflow: hidden，它不改变溢出行为，也不影响滚动逻辑，调试时不会误判“为什么文字不见了”。
立即学习“前端免费学习笔记（深入）”；
- 旧项目需兼容IE11？只能退回
overflow: hidden或display: table-cell - 若右侧内容本身需要滚动（比如日志预览框），
flow-root仍可配overflow-y: auto，互不干扰 - Vue/React组件中动态切换布局时，
flow-root比反复改overflow值更稳定
为什么float + overflow: hidden组合在移动端容易出问题？
不是CSS失效，而是viewport缩放、字体渲染差异、以及iOS Safari对BFC边界的判定更敏感。典型现象是右侧文字突然右移几像素、或首行缩进错乱。
根本原因是float本身已属过时布局模型，和视口单位（vw）、弹性字号（clamp()）配合时，计算时机不一致。
- 避免在
@media (max-width: 768px)里单独重写overflow值，优先用flow-root一劳永逸 - 如果必须用
float（比如维护老后台），给图片加max-width: 100%和height: auto，防止宽图撑破容器 - 检查是否有
* { box-sizing: border-box }缺失——没这句，padding会额外挤占右侧可用宽度
真正该警惕的：float没清除导致后续元素塌陷
很多人加了overflow: hidden就以为万事大吉，结果下面的<footer>直接叠在浮动图片底下。这是因为overflow: hidden只作用于当前元素，不清理父容器里的浮动流。
也就是说：右侧内容自适应了，但整个布局可能已经漏气。
- 父容器必须自己清除浮动，要么加
::after { content: ""; display: table; clear: both; }，要么用display: flow-root（它天然包含清除效果） - 别依赖
overflow: hidden来“顺便”清浮动——它只是副作用，且在某些安卓WebView里不可靠 - 如果父容器高度为0，先检查是否漏了清除，而不是急着调
min-height
浮动布局的坑不在语法多难，而在它的影响是隐式的：改一处，三处跟着偏移。现在用flow-root或直接上display: flex，反而更省调试时间。
