根本原因是滚动条默认叠加在内容区外并额外占位，box-sizing: border-box可将其纳入width计算；Flex中还需子项设min-width: 0解除默认锁死。
overflow:auto 触发滚动条时会占用容器空间
根本原因是：滚动条默认是“叠加在内容区域之外”的，它不计入 width 和 height 的计算，而是额外占位。当内容溢出、overflow: auto 激活滚动条后，浏览器会在容器右侧（垂直滚动条）或底部（水平滚动条）硬生生挤出一块空间——这块空间来自父容器的 padding 或 content-box 区域，导致内容区实际可用宽度突然变窄。
常见现象：overflow: auto 一开，文字换行位置变了、图片被压缩、Flex 子项错位，甚至触发二级水平滚动条（尤其在旧版 IE 或未设 box-sizing 时）。
-
box-sizing: border-box是最直接的缓解手段：它把滚动条宽度纳入width总量内，避免“额外挤占” - 若需精确控制，优先用
scrollbar-gutter: stable（现代浏览器支持），它会为滚动条预留固定空白，无论是否显示都保持布局稳定 - WebKit 浏览器可用
::-webkit-scrollbar固定宽度，但仅限 Chrome/Safari，且不解决 Firefox/Edge 的差异
为什么 overflow:auto 在 Flex 容器里更难预测宽度变化
Flex 子项默认带 min-width: auto（主轴为 row 时），这会让子项“宁可撑破容器也不缩小”。一旦子项内容过宽，overflow: auto 就失效——因为父容器根本没有“溢出边界”，它被子项一路撑开，根本不会触发滚动条。
此时你看到的“宽度变化”，其实是父容器被动拉伸 + 子项又因 min-width: auto 锁死收缩能力，最终整个布局失衡。
立即学习“前端免费学习笔记（深入）”；
- 必须显式重置：给子项加
min-width: 0（row 主轴）或min-height: 0（column 主轴） - 父容器需有明确约束：比如
width: 100%或max-width: 600px，否则 Flex 容器自身 width 仍是auto -
overflow-x: auto比overflow: auto更安全，避免误触发垂直滚动干扰布局
table 布局中 overflow:auto 导致列宽错乱
表格本身有独立渲染逻辑：table-layout: auto（默认）下，列宽由内容决定，width 百分比无效；一旦外层容器设了 overflow: auto，横向滚动出现，但列宽仍按原始内容撑开，结果就是“滚动能看到全列，但视觉上列被压扁或文字溢出”。
这不是 overflow 本身的问题，而是表格和滚动容器之间尺寸传递断裂了。
- 必须配合
table-layout: fixed，让列宽真正响应百分比或width设置 - 给
<col>或<colgroup></colgroup>显式设宽，比单纯靠 CSS 更可靠 - 小屏下建议加
min-width: fit-content防止列被压缩成不可读的细线
overflow:auto 不生效却悄悄影响宽度的隐蔽场景
最易被忽略的是：哪怕滚动条没显示，overflow: auto 也可能改变盒模型行为。例如某些浏览器（尤其是旧版 Safari）在触发 BFC 时，会隐式调整边距折叠或包含块计算，间接影响宽度继承链。
另一个典型是 position: absolute 元素父容器设了 overflow: auto：虽然绝对定位元素本不参与流式布局，但父容器创建 BFC 后，可能改变其 top/left 的参考系或裁剪边界，进而影响渲染宽度判断。
这种影响没有报错，也不直观，往往只在特定设备或缩放比例下暴露——调试时得关掉 overflow 对比 layout 面板里的 computed width 才能确认。
