overflow不改变盒模型计算规则，而是依据box-sizing、width/height、padding、border共同决定的容器内容区尺寸来判断是否溢出，并控制溢出后的表现（裁剪或滚动）。
overflow 本身不改盒模型计算规则，但它依赖盒模型的尺寸结果来决定是否触发裁剪或滚动——换句话说，box-sizing、width/height、padding、border 共同决定了“有没有溢出”，而 overflow 决定“溢出了怎么办”。
盒模型尺寸直接决定 overflow 是否生效
溢出不是凭空发生的，它严格取决于内容实际占用空间与容器可用内容区域的对比：
-
box-sizing: content-box（默认）下，width: 200px+padding: 16px→ 可用内容宽度只剩168px，文字或子元素超此即触发overflow: auto -
box-sizing: border-box下，width: 200px已包含padding和border，内容区自动压缩，更易预估是否溢出 - 若父容器是
display: flex或display: grid，且未设min-width: 0或width: 0，子元素内长文本可能撑开容器，导致overflow: hidden失效
overflow: hidden 不总是“真隐藏”
表面看是裁剪，实际常因 BFC 触发条件缺失而失效：
- 父元素用了
float、position: absolute或display: inline-block→overflow: hidden不创建 BFC，裁剪无效 - 子元素是
position: absolute→ 它已脱离文档流，overflow: hidden对它完全不起作用 - 验证方法：给父容器加
border: 1px solid red，观察溢出内容是否穿出边框 - 修复手段：确保父容器是常规流块级元素；必要时加
display: flow-root（比overflow: hidden更语义清晰）
overflow: auto 的滚动条会吃掉内容宽度
滚动条不是“画上去的装饰”，它真实占据容器内部空间，这点在不同平台表现不一：
立即学习“前端免费学习笔记（深入）”；
- Windows 下 Chrome 默认显示滚动条，占约
17px，导致内容区突然变窄，可能引发布局抖动 - macOS Safari 默认隐藏滚动条，但滚动时才出现，
overflow: auto判定“是否溢出”可能滞后 - 若用
overflow-y: auto+overflow-x: hidden，Firefox 可能因横向内容撑开而忽略纵向滚动——加min-width: 0到父容器可强制参与 flex/grid 尺寸收缩 - 想隐藏滚动条但保留滚动能力？
::-webkit-scrollbar { display: none }（Chrome/Edge）或scrollbar-width: none（Firefox），但别忘了测试触屏设备是否仍可滑动
text-overflow: ellipsis 必须配齐三件套
单行文本省略号看着简单，漏一个就白写：
- 必须同时满足：
overflow: hidden（裁剪）、white-space: nowrap（禁止换行）、text-overflow: ellipsis（渲染省略号） - 若容器是 flex 子项，默认
min-width: auto，长文本会撑宽容器 → 需显式加min-width: 0 - 多行省略不用
text-overflow，得靠-webkit-line-clamp，且只对display: -webkit-box生效 - 注意：
overflow: hidden会同时裁掉::before/::after伪元素，如果省略号逻辑依赖它们，得换方案
真正难的不是记住 overflow 有哪几个值，而是每次写之前得想清楚：这个容器的盒模型尺寸到底由什么决定？内容会不会脱离文档流？滚动条要不要占位？用户是在桌面还是触屏上操作？这些细节没对齐，overflow 就只是个摆设。
