nav 包裹 ul 是最稳妥的垂直导航栏 html 结构，语义正确、支持键盘导航与屏幕阅读器识别；li 中放 a 保证 tab 可聚焦，分组标题用 h3 或 aria-disabled="true" 的 a；css 需重置 ul 默认边距，a 设 display: block/ flex 确保 hover 热区完整。
垂直导航栏的 HTML 结构怎么选：nav + ul 还是 div 套 a？
语义正确性和可访问性直接决定菜单能不能被屏幕阅读器识别、SEO 是否友好。用 nav 包裹 ul 是最稳妥的选择，li 里放 a 能让键盘 Tab 导航自然停在每个菜单项上。
- 别用一堆
div+onclick模拟链接——它不会出现在页面链接列表里，也无法用键盘跳转 - 如果某菜单项只是分组标题（无跳转），用
h3或带aria-disabled="true"的a，别塞进li当可点击项 -
ul默认有上下外边距和左侧内边距，重置时记得清掉margin和padding-left，否则顶部/底部留白不可控
CSS 实现垂直对齐和 hover 效果的关键陷阱：伪类和 display 冲突
很多人写 a:hover 没反应，其实是被父级 display: inline 或未设 height 卡住了。垂直导航栏必须让每个菜单项有明确的点击热区，不能只靠文字撑开。
- 给
a设display: block或display: flex，否则:hover只在文字区域生效 - 用
line-height控制高度时，注意字体实际渲染会略高于设定值，建议改用padding（如padding: 12px 20px）更稳 - 图标+文字组合时，避免用
float或position: absolute破坏流式布局；推荐display: flex+align-items: center
子菜单展开逻辑该用 CSS 还是 JS？看这三点再决定
纯 CSS 实现（:hover 或 :focus-within）快且轻量，但 iOS Safari 不支持 :hover，移动端点不展开；JS 控制更可控，但得自己管焦点、键盘操作和屏幕阅读器状态。
- 如果只要桌面端、且无嵌套超过 1 层，用
:hover > .submenu最省事 - 要兼容手机或需键盘操作（比如按方向键切换子项），必须用 JS，并给子菜单加
aria-expanded和aria-hidden - 别在
transition里只写height——从0到auto不触发动画，改用max-height或transform: scaleY()
移动端折叠后如何保持语义和功能完整？别只藏 display: none
单纯用 display: none 隐藏侧边栏，会让屏幕阅读器彻底忽略整个导航，也断掉键盘 Tab 流。折叠不是删除，是“换种方式呈现”。
立即学习“前端免费学习笔记（深入）”；
- 用
visibility: hidden+position: absolute+clip-path或inset把菜单移出视口，同时保留 DOM 和可访问性 - 汉堡按钮必须有
aria-controls="nav-id"，对应菜单容器加id="nav-id"和role="navigation" - 展开后记得把焦点移到第一个菜单项：
document.querySelector("#nav-id a").focus()，否则键盘用户卡在按钮上
垂直导航栏最难的不是样式，是让每一种交互路径（鼠标悬停、触屏点击、键盘 Tab、屏幕阅读器朗读）都走通。一个没设 tabindex 的图标，或漏掉的 aria-current，就可能让整块功能对部分用户失效。
