垂直菜单自适应高度的本质是让父容器根据内容自然撑开，关键在于避免使用height、max-height、position: absolute或浮动等破坏文档流的样式；语义化结构（nav>ul>li>a）和min-height才是正确实践。
垂直菜单的自适应高度根本不用“掌握”，它本来就会——只要你没用 height、max-height、position: absolute 或浮动未清除这些规则强行锁死或脱离文档流。
为什么菜单突然不随内容变高了？
不是 HTML/CSS 失效了，而是你（或框架生成的代码）悄悄加了限制：
-
height: 100%或height: 200px：直接固定高度，内容再多也溢出或被裁剪 -
max-height: 250px+overflow: hidden：内容超限后不可见，且父容器不会撑开 -
float: left的菜单容器没触发 BFC（比如没加overflow: hidden或伪元素清除），导致父容器高度塌陷为 0 - 用了
display: flex但父容器没设高度，子项又写了align-self: flex-start，放弃拉伸
垂直菜单结构必须用 <nav><ul><li><a></a></li></ul></nav> 套路
别用一堆 <div> 堆，否则语义丢失、屏幕阅读器读不出导航意图、后期加下拉或 JS 控制都难：
<ul>
<li>必须用 <code><nav></nav> 包裹，这是语义化导航区域的唯一标准标签
<ul></ul> 是菜单项的天然容器，list-style: none 可关序号，比用 <ol></ol> 或 <div> 更合理
<li>每个菜单项必须是 <code><li><a></a></li>，不能把 <a></a> 直接塞进 <nav></nav> —— 否则无法用 CSS 选中所有项统一控制高度aria-current="page" 标识，比仅靠 class="active" 更健壮（尤其 SSR 或动态渲染场景）
min-height 是唯一需要主动写的高度相关样式
height: auto 是默认值，写不写都一样；真正起作用的是 min-height，它既保底又放行：
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- 想让菜单至少显示 160px 高，但内容有 20 条时自动撑到 400px → 写
min-height: 160px - 如果同时写了
height: 160px，min-height就失效，变成固定高度 - 配合
box-sizing: border-box，确保 padding 和 border 不额外撑高容器 - 滚动需求另说：要固定高度+滚动，才用
max-height+overflow-y: auto，和自适应是两回事
Flex 布局里菜单高度“不变化”其实是正常现象
很多人在 Flex 容器里写了个 <nav></nav>，发现它不随链接数量变高，就以为出错了——其实没坏，只是理解反了：
- Flex 子项默认
align-items: stretch，但前提是父容器有明确高度（比如height: 500px）。如果父容器本身高度由内容决定，那子项自然退回内容高度 - 你想要菜单“填满剩余空间”，应该给它加
flex: 1，而不是设height: 100% - 若菜单内有
position: absolute的下拉层，它不影响父容器高度计算，得用padding-bottom或伪元素模拟占位，否则滚动或点击会错位
最常被忽略的一点：自适应高度和滚动是互斥需求。你要么让菜单完全随内容舒展（此时不需要任何高度声明），要么限定最大高度并启用滚动（此时必须用 max-height 而非 height）。混用两者只会让布局反复失效。
