nav中二级菜单必须严格遵循语义层级：子菜单ul必须是li的直接子元素，且触发li需设position: relative以定位绝对子菜单；css显隐应避免display: none以保障无障碍访问。
nav 里嵌套 ul 的层级必须严格对应语义
不是所有 <nav></nav> 都能自然撑起二级菜单逻辑，关键在 <ul></ul> 嵌套是否形成“父项包含子项”的 DOM 层级。浏览器不认“看起来像菜单”的结构，只认 <li> 里直接包裹 <ul></ul> 这一事实。
常见错误是把子菜单写在 <li> 外面，比如：
<nav><ul>
<li>产品</li>
<ul class="submenu"><li>硬件</li></ul>
</ul></nav>
这样 .submenu 和“产品” <li> 没有父子关系，li:hover .submenu 根本选不到——CSS 选择器不会跨兄弟节点匹配。
正确结构必须是：
<nav><ul class="primary-menu">
<li>
<a href="#">产品</a>
<ul class="submenu">
<li><a href="/hardware">硬件</a></li>
<li><a href="/software">软件</a></li>
</ul>
</li>
</ul></nav>
-
<nav></nav>是语义容器，不参与定位或显隐控制 - 一级
<ul></ul>是主菜单流式布局基础，通常设display: flex或float: left - 每个可展开的
<li>必须同时包含<a></a>和其直属<ul class="submenu"></ul> - 子菜单
<ul></ul>必须是该<li>的**直接子元素**，不能隔层（如套了<div>）<h3>position: relative 必须加在触发 hover 的 li 上</h3> <p>子菜单用 <code>position: absolute定位，但它的参考系是谁？不是<nav></nav>，也不是外层<ul></ul>，而是它最近的、设置了position: relative的祖先 —— 也就是那个带子菜单的<li>。如果漏掉这句，
.submenu会相对于整个页面或最近的定位祖先偏移，导致错位甚至飞出视口。典型写法：
Html To Pdf下载使用 Puppeteer + Chrome 将 HTML 渲染为中文 PDF，自动处理图表等待、Tab 展开、动画、测高、白边消除、防分页，适用于看板、报表、网页和交互图表转 PDF。
.primary-menu li { position: relative; /* 关键！没有它，top: 100% 就失效 */ } .submenu { position: absolute; top: 100%; left: 0; display: none; } .primary-menu li:hover .submenu { display: block; }- 不要给
<nav></nav>或外层<ul></ul>加position: relative—— 它们只是容器，不是定位锚点 - 如果用了
flex布局一级菜单，li默认不占文档流高度，加position: relative不影响布局 - 移动端若用
:focus-within替代:hover，同样依赖这个position: relative锚点
display: none 和 visibility: hidden 的行为差异直接影响键盘导航
纯 CSS 二级菜单若只靠
display: none控制显隐，在键盘 Tab 导航时会出现两个问题：子菜单项无法被聚焦、屏幕阅读器读不到隐藏内容。这不是“能不能用”的问题，而是“要不要支持无障碍”的分水岭。
更稳妥的做法是保留 DOM 可访问性，仅视觉隐藏：
.submenu { position: absolute; clip-path: inset(100%); /* 推荐：完全隐藏且不影响焦点流 */ /* 或者用传统组合： */ /* position: absolute; */ /* opacity: 0; */ /* pointer-events: none; */ /* transition: opacity 0.2s; */ }-
display: none会让元素彻底退出渲染树和焦点流，Tab 键跳过整个子菜单 -
visibility: hidden保留占位，可能撑开父容器高度，破坏纵向菜单紧凑感 -
clip-path: inset(100%)是现代方案：视觉不可见、仍可聚焦、不影响布局 - 若用
opacity + pointer-events，记得加transition，否则 hover 切换生硬
纵向菜单中 float 和 flex 的兼容性取舍
纵向二级菜单常被误认为“必须用
float”，其实flex更干净，但要注意老版本 Safari 对flex-direction: column下li:hover > ul的支持不稳定。当前（2026 年）推荐优先用
flex，但需规避一个坑：.primary-menu { display: flex; flex-direction: column; /* 纵向排列 */ } .primary-menu li { position: relative; } /* ❌ 错误：flex 容器下，:hover 直接子 ul 不会自动宽度继承 */ .primary-menu li:hover > ul { width: 100%; /* 必须显式设置，否则 collapse */ }- 用
float时，一级<li>需要clear: both防止浮动塌陷，代码更啰嗦 - 用
flex时，子菜单<ul></ul>默认宽度为 0，必须设width: 100%或min-width: max-content - IE11 不支持
flex-direction: column下的 hover 子选择器，如需兼容，退回float方案
实际做纵向二级菜单时，最易被忽略的是子菜单的宽度继承逻辑和键盘焦点路径 —— 这两点不处理，菜单在真实用户场景里基本等于不可用。
- 不要给
