height: auto 的本质是内容驱动高度，即浏览器根据参与正常文档流的子元素和文本行盒自动计算content height，再叠加padding与border得到视觉总高度。
height: auto 的本质是“内容驱动高度”
当一个块级元素没写 height，或显式设为 height: auto，它的高度就不是你“定出来”的，而是浏览器根据内容自动算出来的——这个“内容”，特指**参与正常文档流（normal flow）的子元素和文本行盒（line boxes）**。
- 子元素要是
display: block、flex、grid、table等，默认参与高度计算；但float、position: absolute/fixed的子元素会完全脱离文档流，父容器“看不见”它们，也就不会被撑开 - 纯文本也会撑高：哪怕只有一个字，只要没被
line-height或vertical-align拉变形，它就会生成至少一行行盒，贡献基础高度 -
padding和border不参与“撑开逻辑”，但会加到最终总高度里——也就是说，height: auto算出的是 content height，而视觉总高度 = content height + padding-top + padding-bottom + border-top-width + border-bottom-width
为什么加了 padding 却像“没撑开”？
这不是 height 失效，而是你忽略了 padding 本身会增加总高度，同时可能与其他元素发生重叠或错位。比如：
.box {
padding: 20px;
background: #eee;
}
如果里面只有一行文字，它的 content height 可能只有 24px（由字体大小 + line-height 决定），但整个 .box 的视觉高度是 24px + 40px = 64px。如果你没给父容器留足空间，或者父容器设置了 overflow: hidden，就会误以为“没撑开”。
- 检查 computed styles 中的
height值，看是否标注(computed from children)—— 这才是真正的“被撑开”证据 - 用开发者工具逐个禁用子元素的
float或position，观察父高度是否恢复，能快速定位脱离文档流的“隐形元凶” - 别在需要自适应的容器上同时写
height: auto和overflow: hidden，后者会裁剪内容，掩盖真实高度
height: 100% 为什么经常失效？
因为 height: 100% 是向父元素“要高度”，而父元素若仍是 height: auto（即没有确定高度），那 100% 就等于 0px —— 浏览器没法从一个未定义的值里算出百分比。
立即学习“前端免费学习笔记（深入）”；
- 常见错误：
.parent { height: auto; } .child { height: 100%; }→ 子元素实际高度为 0 - 正确替代方案：用布局机制接管，比如父设
display: flex; flex-direction: column;，子设flex: 1，就能自然填满可用空间 - Grid 更直接：
.parent { display: grid; grid-template-rows: 1fr; }，子元素自动占满 - 注意兼容性：
flex: 1在 IE11 中某些嵌套下行为异常，必要时写成flex: 1 1 0
哪些操作会让父容器“假装看不见”子元素？
不是子元素没高度，而是它没进入父容器的高度计算流程。最典型的三类干扰：
-
浮动子元素：
float: left后，子元素脱离文档流 → 父高度塌陷为 0。解决：父设display: flow-root（推荐），或伪元素清除：::after { content: ""; display: table; clear: both; } -
绝对定位子元素：
position: absolute→ 父容器对其高度完全无感知。若需视觉占位，得手动加min-height或用伪元素模拟高度 -
Flex/Grid 容器设了 max-height：即使子项设
align-self: stretch，一旦父容器max-height被触发，内容就会被截断，看起来像“撑不开”
真正决定高度的，从来不是某个属性单独起作用，而是盒模型 + 文档流 + 布局上下文共同作用的结果。盯着 height 改来改去，不如先确认子元素是否还在文档流里——这是绝大多数“撑不开”问题的起点。
