子元素height: 100%失效的根本原因是父容器computed height为auto，导致浏览器计算出100%×0px=0px；必须逐层检查html、body及所有中间父级的computed height是否均为具体像素值，任一层为auto则整条链中断。
子元素的 height: 100% 不生效，根本不是它写错了，而是浏览器压根没算出“100%”该等于多少像素——父容器的 height 是 auto，乘出来就是 100% × 0px = 0px。
为什么父容器 height: auto 就让 height: 100% 彻底失效
浏览器计算子元素 height: 100% 时，只查**直接父元素的 computed height**。如果父容器是 display: flex 但没写 height、min-height 或 flex: 1 撑开自身，那它的 height 就是默认的 auto。
- 哪怕你给子元素写了十层嵌套的
height: 100%，只要中间任意一层是auto，整条链就断了 - 用开发者工具选中父容器 → 切到 “Computed” 面板 → 看
height值：如果是auto或0px，说明它没提供有效参照 - 某些 UI 框架（如 Ant Design）或 CSS reset（如 Normalize.css）会悄悄重置
html或body的height，导致你写了body { height: 100% }却无效
Flex 容器里 height: 100% 和 flex: 1 的冲突逻辑
在 Flex 容器中混用 height: 100% 和 flex 属性，常因优先级覆盖而白忙活。子元素一旦声明 height: 100%，浏览器就认为你手动接管高度控制，自动忽略 align-items: stretch 的拉伸行为。
-
flex: 1等价于flex: 1 1 0，其中flex-basis: 0是关键——它让元素从零开始拉伸，不依赖父容器已有像素高 - 但
flex: 1也不是万能开关：父容器必须是display: flex，且自身得有高度来源（比如height: 100vh或被上层flex: 1撑开） - 子元素若被框架注入了
min-height: 0（常见于表格行、按钮等），会锁死拉伸能力，需显式覆盖为min-height: auto或min-height: 0（视场景而定）
Safari 14–15.6 和旧版 Chrome 的特殊坑
这些版本对 height: 100% 的处理不是“兼容性差”，而是引擎级限制：它们压根不把 Flex 容器识别为有效高度上下文，哪怕父容器写了 height: 100vh，子项的 height: 100% 仍被忽略。
- Safari 14–15.6：不认
min-height、flex: 1推导出的高度，只接受显式height声明；甚至加!important也无效 - Chrome 49 及更早：Blink 内核不将
flex: 1撑开的父容器当“有高度”，必须逐层写死height（如.layout { height: 100vh }） - 真正容易被忽略的，是没打开开发者工具逐层点开看 —— 你以为链路通了，其实
html或某层.wrapper的 computedheight仍是auto
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
