必须用ul包裹li构建导航菜单，因ul/li提供不可替代的语义结构：屏幕阅读器据此播报列表项、搜索引擎识别导航意图、CSS选择器精准控制、键盘焦点正确遍历，且多级菜单必须严格嵌套在li内才能保证交互与可访问性。
ul 和 li 是构建 HTML 导航菜单最可靠、语义最清晰的基础结构，不是“能用”，而是“必须用”——其他方式（比如纯 div 堆砌）会破坏可访问性、SEO 和维护性。
为什么必须用 ul 包裹 li 而不是随便套 div
屏幕阅读器会把 ul 识别为“列表”，自动播报“共 X 项”，而 div 只是普通容器，毫无语义；搜索引擎也依赖这种结构理解导航意图。更实际的是：CSS 选择器如 nav ul li a 能精准命中链接，但 nav div div a 容易误伤其他内容。
常见错误现象：
- 把子菜单的
ul写在父li外面，导致二级项变成平级项 - 漏写
li的闭合标签，后续所有嵌套错位，浏览器渲染出完全不可预测的结构 - 给
ul加了display: inline，却忘了清除默认padding-left，结果菜单整体右偏
ul 和 li 的基础样式重置必须做
浏览器对 ul 默认加了 padding-left: 40px 和 margin，不重置就会撑开导航栏、文字错位。这不是“美化问题”，是布局前提。
立即学习“前端免费学习笔记（深入）”；
实操建议：
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- 统一在开头写
ul, ol { list-style: none; padding: 0; margin: 0; } - 每个
li必须设display: inline-block或用display: flex父容器控制，不能只靠float且不清理浮动 -
a标签一定要设display: block，否则padding不生效，点击热区极小
多级下拉菜单的 li 嵌套必须严格闭合
二级菜单本质是某个 li 的子内容，所以它的 ul 必须完整写在该 li 的起始与结束标签之间。这是 HTML 结构铁律，不是 CSS 技巧能补救的。
正确结构示例：
<nav>
<ul>
<li><a href="/">首页</a></li>
<li>
<a href="/about">关于</a>
<ul class="dropdown">
<li><a href="/team">团队</a></li>
<li><a href="/history">历程</a></li>
</ul>
</li>
</ul>
</nav>
关键点：
- 子
ul不能放在父li外，也不能跨多个li - 父
li必须设position: relative，否则子菜单的position: absolute会相对于body定位 - 用
li:hover .dropdown触发显示，别用a:hover .dropdown——鼠标离开链接文字但还在li区域时，菜单会闪退
Flexbox 布局下 ul 和 li 的角色没变，但控制逻辑变了
用 display: flex 替代浮动后，ul 变成 flex 容器，li 是 flex 项目，但它们的语义和嵌套规则完全不变。变化的是布局手段。
容易踩的坑：
- 给
ul设display: flex后，忘了设flex-wrap: nowrap，小屏下菜单直接换行挤成两行 - 给
li设flex: 1想等宽，但没限制最小宽度，导致文字被压缩或折行 - 媒体查询里只改
nav的flex-direction，却没隐藏桌面端的下拉菜单，移动端点一下就展开一堆无用子项
真正难的从来不是怎么让菜单横过来，而是确保它在键盘焦点、屏幕阅读器、窄屏、缩放 200% 时都依然可操作——这些全靠 ul/li 的语义骨架撑住，而不是某段炫酷的 CSS 动画。
