导航设计这件事，说简单也简单，说复杂也复杂。简单在于，任何一个写过几个页面的人都能摆出一个导航栏；复杂在于，当信息层级从一层变成两层、三层，当屏幕从桌面宽屏缩到手机窄屏，当用户从"随便逛逛"变成"必须快速找到某个功能"，导航就从"摆几个链接"变成了一整套信息架构的落地工程。我见过太多项目，视觉稿上导航漂漂亮亮，一上线就露馅：二级菜单在触屏上点不开、三级导航在窄屏里直接溢出、当前页面高亮状态错乱、键盘 Tab 键走一圈焦点不知道飞哪去了。这些问题不是审美问题，是结构问题。
这篇内容想聊的，就是把导航从"横向一条"做到"三级嵌套"这条路上，那些真正决定成败的东西：信息层级怎么切、横向导航和侧边导航各自适合什么场景、多级菜单的展开逻辑怎么设计才不反人类、响应式断点下导航如何优雅降级、以及可访问性和状态管理这些容易被忽略但一测就出事的细节。不管你是刚接触前端布局的新手，还是已经做过几个中后台项目、想把导航体系梳理清楚的老手，下面这些从实际项目里磨出来的经验，应该都能直接拿去用或者拿去改。我会尽量把每个"为什么这么设计"讲透，而不是只丢一堆 CSS 给你抄。
1. 先想清楚导航到底在解决什么问题
很多人做导航的第一反应是打开设计稿，量一量高度、间距、字号，然后开始写 flex 布局。这个顺序其实是反的。导航的本质是信息架构的可视化出口，它要回答的是"用户现在在哪、能去哪、怎么回去"这三个问题。你把这三个问题想明白了，样式只是水到渠成的事；想不明白，再精致的导航也是个摆设。
1.1 导航的三层职责：定位、寻路、层级表达
我习惯把导航的职责拆成三层来看。第一层是定位，也就是"我在哪"。这对应的是当前页面的高亮状态、面包屑、以及菜单项的激活样式。第二层是寻路，也就是"我能去哪"。这对应的是导航项的组织方式、分组逻辑、以及哪些入口要前置。第三层是层级表达，也就是"这个站点/系统有多深"。这对应的是多级菜单的展开方式、层级之间的视觉区分。
这三层职责里，最容易被做坏的是第三层。因为前两层是"看得见"的，定位靠高亮、寻路靠链接，而层级表达是"感觉得到"的。一个三级导航如果层级表达没做好，用户点进第三级页面后会产生强烈的迷失感——不知道自己是从哪个二级栏目进来的，也不知道返回上一级该点哪里。这种迷失感在后台管理系统里尤其致命，因为后台用户往往是带着明确任务来的，迷路一次就可能直接放弃使用。
所以我在动手写任何导航代码之前，会先在纸上把信息层级画出来：一级有几个、每个一级下面挂几个二级、哪些二级需要再往下分三级。画完之后再问自己一个问题——这个层级深度是业务真的需要，还是我们偷懒把所有东西都塞进来了？大多数情况下，三级导航之所以让人头疼，根源在于信息没有经过收敛，而不是导航组件本身不够强。
1.2 横向导航与侧边导航的适用边界
横向导航和侧边导航不是审美选择，是场景选择。横向导航（顶部一条）适合一级入口数量少、层级浅、且需要给内容区留出完整宽度的场景，典型如官网、内容型站点、营销页。侧边导航适合一级入口多、层级深、且用户需要在多个模块间频繁切换的场景，典型如后台管理系统、工具型应用。
这里有个很实用的判断标准：数一数你的一级入口有几个。如果超过七个，横向导航在中等宽度屏幕上就会开始拥挤，字号被迫缩小、间距被迫压缩，可读性直线下降。这时候要么做"更多"折叠，要么干脆换成侧边导航。反过来，如果一级入口只有三四个，却硬要做成侧边导航，那左侧一大片空白会显得整个界面重心失衡，内容区被无谓地挤压。
还有一个常被忽略的维度是使用频率。横向导航的视觉权重高，用户扫视时第一眼就会看到，适合放高频入口；侧边导航的视觉权重相对低，但常驻性强，适合放那些"不常用但不能没有"的模块入口。我在一个内容管理项目里就吃过亏：把"数据统计"这种每天都要看的入口放进了侧边导航的折叠分组里，结果运营同学天天抱怨找不到。后来把它提到侧边导航顶部独立分组，问题立刻消失。导航的位置，本质上是在分配用户的注意力预算。
1.3 层级深度与用户认知负荷的平衡
信息架构里有个经验法则：每增加一层，用户的认知负荷就上升一档，到达第三层时，用户的耐心通常已经接近临界。这不是说三级导航不能做，而是说做到第三级时，你必须用更强的视觉线索和更明确的返回路径来补偿。
具体怎么补偿？第一，三级菜单的展开要有明确的"父级归属感"，比如二级项展开时保持高亮、三级项缩进并带连接线或背景色区分。第二，进入三级页面后，面包屑必须完整显示"一级 > 二级 > 三级"的路径，且每一级都可点击返回。第三，三级页面内部不要再出现第四级导航，如果业务真的需要四层，那说明信息架构该重构了，而不是导航组件该升级了。
我见过一个反例：某系统的导航做到了四级，第四级是弹窗里再套一个下拉。用户点进去之后完全不知道自己身处何处，返回按钮点了三次才回到首页。这种设计的问题不在于技术实现，而在于把"层级"当成了"收纳盒"，什么东西都往里塞。导航的深度应该由信息的真实归属关系决定，而不是由"没地方放了"决定。
2. 横向导航的落地：从结构到状态
横向导航看起来是最简单的一种，但真正做扎实，需要处理的东西一点不少：结构语义、激活状态、溢出处理、以及和内容区的联动。下面按实际动手的顺序拆开讲。
2.1 语义化结构：为什么用 nav 和 ul 而不是一堆 div
我见过太多横向导航是用一串 div 加 span 堆出来的，样式上没问题，但语义上一塌糊涂。屏幕阅读器读到这些 div 时，无法识别这是一个导航区域，也无法告诉用户"这里有 5 个导航项，当前在第 2 项"。用<nav>包裹、用<ul>和<li>组织列表、用<a>承载跳转，这不是形式主义，而是让辅助技术能够正确解析导航结构的前提。
一个规范的横向导航结构大致是这样：
<nav aria-label="主导航"> <ul class="nav-list"> <li class="nav-item"><a href="/" class="nav-link is-active" aria-current="page">首页</a></li> <li class="nav-item"><a href="/products" class="nav-link">产品</a></li> <li class="nav-item"><a href="/docs" class="nav-link">文档</a></li> </ul> </nav>这里有两个细节值得说。aria-label="主导航"是为了在页面存在多个 nav 区域时（比如顶部主导航加底部页脚导航）让屏幕阅读器能区分它们。aria-current="page"则是告诉辅助技术"当前链接指向的就是当前页面"，它比单纯加一个.is-active类更有语义价值——视觉高亮是给人看的，aria-current是给机器读的，两者要同时存在。
提示：
aria-current的取值不止page，还有step（流程中的当前步骤）、location（当前所在位置，常用于面包屑）、date、time等。导航项用page，面包屑用location，别混用。
2.2 激活状态与路由的同步逻辑
激活状态错乱是横向导航最高频的 bug。典型表现是：刷新页面后高亮丢了、从二级页面返回一级时高亮没更新、或者多个菜单项同时高亮。根因通常是把"高亮"当成了静态样式，而不是路由状态的映射。
正确的做法是让激活状态完全由当前路由推导出来，而不是手动在某个点击事件里加类。以常见的单页应用为例，导航项的激活判断应该基于当前路径与导航项路径的匹配关系。这里有个坑：如果一级导航项是/products，而用户当前在/products/detail/123，简单的全等匹配会导致一级项不高亮。所以匹配逻辑要区分"精确匹配"和"前缀匹配"——首页这类根路径用精确匹配，其余一级项用前缀匹配。
function isActive(itemPath, currentPath) { if (itemPath === '/') return currentPath === '/'; return currentPath === itemPath || currentPath.startsWith(itemPath + '/'); }这段逻辑看着简单，但它解决的是"用户在深层页面时，一级导航仍然知道自己属于哪个栏目"的问题。我在一个项目里就是因为漏了前缀匹配，导致用户进到详情页后顶部导航全部变灰，用户以为系统坏了。这种 bug 不报错、不崩溃，但体验上的伤害一点不小。
2.3 横向导航的溢出处理：折叠还是滚动
当一级入口变多、屏幕变窄时，横向导航必然面临溢出。两种主流处理方式：折叠进"更多"菜单，或者横向滚动。这两者没有绝对优劣，取决于入口的重要程度分布。
如果一级入口有明显的主次之分，用折叠更合适——把次要入口收进"更多"，保证主要入口始终可见。如果所有入口重要程度相当，且用户需要快速横向扫视对比，横向滚动更合适，但要记得加滚动提示（比如右侧渐隐遮罩），否则用户不知道右边还有内容。
折叠方案里有个细节容易翻车：折叠的触发阈值不能写死成某个像素值，而应该基于实际内容宽度动态判断。因为导航项的文字长度是会变的（多语言、运营改文案），写死阈值的结果就是某些语言下折叠过早、某些语言下溢出。比较稳妥的做法是用ResizeObserver监听导航容器宽度，结合各项的实际宽度计算需要折叠几项。这个实现成本略高，但对于入口多、文案会变的项目，值得投入。
3. 侧边导航与多级菜单的展开逻辑
侧边导航是多级菜单的主战场。横向导航做三级会非常别扭（下拉里再套下拉，鼠标稍微一抖就全关了），而侧边导航天然适合纵向展开，层级关系一目了然。但"适合"不等于"自动就好用"，展开逻辑的设计才是关键。
3.1 手风琴模式与多开模式的取舍
多级侧边菜单有两种基本展开模式：手风琴模式（同一时间只展开一个分组，展开新的自动收起旧的）和多开模式（可以同时展开多个分组）。这两种模式的选择，取决于用户的使用模式。
手风琴模式适合"用户一次只专注一个模块"的场景，界面始终清爽，不会因为展开太多而需要滚动。多开模式适合"用户需要在多个模块间来回切换"的场景，避免反复展开收起的操作成本。我在后台项目里的默认选择是多开，因为后台用户经常需要在"订单"和"用户"两个模块间跳转，手风琴模式会让他们每次切换都多两次点击。
但多开模式有个副作用：展开的分组多了之后，侧边栏会变得很长，用户需要滚动才能看到下面的入口。这时候要考虑是否在展开时自动滚动到可视区域，以及是否提供"全部收起"的快捷操作。这些细节不影响功能，但直接影响日常使用的顺手程度。
3.2 三级菜单的缩进、连线与视觉层级
三级菜单最容易出的问题是"层级看不出来"。二级项和三级项如果只是字号差一点、缩进差一点，用户在快速扫视时根本分不清谁是谁的子项。我的做法是用三重线索叠加：缩进 + 连接线 + 背景色。
缩进是最基础的，每一级增加固定的左内边距（比如每级 16px 或 20px）。连接线是在三级项左侧画一条竖线，从二级项的位置延伸下来，明确表达"这些三级项属于上面那个二级项"。背景色则是让展开的二级分组有一个轻微的底色区分，把整个分组"框"起来。三重线索叠加之后，即使快速扫视也能看清层级关系。
.nav-level-2 { padding-left: 20px; } .nav-level-3 { padding-left: 40px; position: relative; } .nav-level-3::before { content: ''; position: absolute; left: 28px; top: 0; bottom: 0; width: 1px; background: var(--border-color); }这里有个经验：连接线的颜色要足够淡，淡到不抢内容，但又要在浅色背景上看得见。我一般用比边框色再浅一档的颜色，实测下来既表达了层级又不显脏。
3.3 展开状态与路由的联动：自动展开当前路径
用户直接访问一个三级页面的 URL（比如从收藏夹进来、或者刷新页面），侧边导航应该自动展开到对应的三级项，并高亮它。这个联动如果没做，用户进来看到的是全部收起的菜单，完全不知道自己在哪里，体验非常割裂。
实现思路是：拿到当前路径后，逐级匹配导航配置，找出当前项的所有祖先节点，把它们全部标记为展开状态。这里要注意的是，展开状态应该是"路由推导的初始状态 + 用户手动操作的叠加"，而不是纯路由驱动。因为用户可能手动收起了某个分组，这时候如果路由一变就强制展开，会打断用户的操作意图。比较稳妥的做法是：路由变化时，只自动展开当前项所在的祖先链，不主动收起用户手动展开的其他分组。
function findAncestors(items, currentPath, trail = []) { for (const item of items) { if (currentPath.startsWith(item.path)) { const nextTrail = [...trail, item.key]; if (item.children) { const deeper = findAncestors(item.children, currentPath, nextTrail); if (deeper) return deeper; } return nextTrail; } } return null; }这段递归找祖先链的逻辑，是侧边导航自动展开的核心。它返回的是从根到当前项的 key 数组，拿这个数组去设置展开状态即可。
4. 响应式断点下导航的降级策略
导航在桌面端做得好，不代表在平板和手机上能用。响应式导航的核心不是"把横向导航缩小"，而是"在窄屏下换一种更适合触屏的导航形态"。这个形态切换的时机和方式，决定了移动端体验的下限。
4.1 断点选择：按内容宽度而非设备宽度
很多项目把断点写死成 768px、1024px 这些"经典值"，但实际用起来经常出问题：某些平板横屏时导航挤成一团，某些小笔记本上又过早切换成汉堡菜单。根本原因是断点应该由导航内容本身的宽度需求决定，而不是由设备型号决定。
我的做法是先算出导航在最小可接受状态下的宽度：所有一级项文字宽度之和 + 项间距 + 左右内边距。这个宽度就是横向导航的"生存底线"。当视口宽度低于这个底线时，就该切换形态了。这样算出来的断点可能不是整数，但它是真正贴合内容的。如果导航项是动态的（比如权限不同看到的入口不同），那就用ResizeObserver在运行时判断，而不是靠媒体查询。
4.2 移动端导航的三种形态与选择依据
窄屏下的导航形态主要有三种：汉堡菜单（抽屉式）、底部标签栏、顶部横向滚动。三者的适用场景差别很大。
汉堡菜单适合入口多、层级深的场景，把整个导航收进抽屉，点开后是完整的纵向菜单，层级关系可以完整保留。缺点是入口被隐藏了，用户需要多一次点击才能看到导航，对高频入口不友好。底部标签栏适合入口少（三到五个）、且都是高频核心入口的场景，常驻可见、拇指易达，但不适合承载多级菜单。顶部横向滚动适合入口中等、层级浅的场景，介于前两者之间。
实际项目里经常是组合使用：底部标签栏放三到五个核心入口，汉堡菜单放完整的层级导航。这种组合在工具型应用里很常见，核心操作常驻、完整功能可展开，兼顾了效率和完整性。
4.3 抽屉导航的焦点管理与滚动锁定
移动端抽屉导航有两个技术细节，做不好会直接导致体验崩坏。第一个是滚动锁定：抽屉打开时，背后的页面不应该跟着滚动。这个如果不处理，用户在抽屉里滑动时会发现背景页面在动，非常出戏。实现方式是在抽屉打开时给body加overflow: hidden，关闭时移除。
第二个是焦点管理：抽屉打开时，键盘焦点应该被限制在抽屉内部，Tab 键不应该跑到背后的页面上去；抽屉关闭时，焦点应该回到触发抽屉的那个按钮上。这个对键盘用户和屏幕阅读器用户至关重要。实现上需要在抽屉打开时记录当前焦点元素，把焦点移到抽屉内的第一个可聚焦元素，并在抽屉内做焦点循环（Tab 到最后一个元素后回到第一个）。
function trapFocus(container) { const focusable = container.querySelectorAll( 'a[href], button:not([disabled]), input, select, textarea, [tabindex]:not([tabindex="-1"])' ); const first = focusable[0]; const last = focusable[focusable.length - 1]; container.addEventListener('keydown', (e) => { if (e.key !== 'Tab') return; if (e.shiftKey && document.activeElement === first) { e.preventDefault(); last.focus(); } else if (!e.shiftKey && document.activeElement === last) { e.preventDefault(); first.focus(); } }); }这段焦点陷阱逻辑不长，但它是移动端抽屉导航可访问性的底线。我见过不少项目抽屉打开后按 Tab 键焦点直接跑到背景页面，键盘用户完全没法用。
5. 导航的可访问性与状态管理细节
前面几节讲的是"看得见"的部分，这一节讲"看不见但一测就出事"的部分。导航是页面上被使用频率最高的组件之一，它的可访问性缺陷会被放大到每一个用户身上。
5.1 键盘导航：Tab 顺序与方向键支持
横向导航和侧边导航的键盘交互模式其实不一样。横向导航更接近"菜单栏"模式，理想情况下应该支持左右方向键在项之间移动、回车激活；侧边导航更接近"树"或"列表"模式，上下方向键移动更自然。但现实中，大多数项目只做到了 Tab 键能走通，方向键完全没做。
Tab 键能走通是底线，必须保证。这意味着所有导航项都必须是可聚焦元素（用<a>或<button>，而不是给 div 加点击事件），且 Tab 顺序与视觉顺序一致。方向键支持是加分项，但对于入口多、层级深的导航，方向键能显著提升键盘用户的效率。如果要做，记得同步管理tabindex，让整个导航在 Tab 序列中只占一个位置，进入后用方向键在内部移动，这是标准的"漫游 tabindex"模式。
5.2 多级菜单的展开状态如何避免"状态地狱"
多级导航的状态管理，随着层级增加会迅速复杂化：每个分组的展开/收起、每个项的激活/非激活、当前路径的祖先链、用户手动操作与路由推导的叠加……如果不加约束，很快就会变成一堆布尔值散落各处，改一个地方崩另一个地方。
我的做法是把导航状态收敛成一个结构化的对象，而不是散落的布尔值。展开状态用一个Set存展开项的 key，激活状态由路由推导，两者分离。用户操作只改展开集合，路由变化只影响激活项和祖先链的自动展开。这样职责清晰，调试时也容易定位问题——展开不对就查展开集合，高亮不对就查路由匹配。
| 状态类型 | 数据来源 | 变更时机 | 常见问题 |
|---|---|---|---|
| 展开状态 | 用户操作 + 路由祖先链 | 点击展开/收起、路由变化 | 路由变化时误收起用户手动展开项 |
| 激活状态 | 当前路由推导 | 路由变化 | 前缀匹配缺失导致深层页面不高亮 |
| 悬停状态 | 鼠标/触摸事件 | 移入移出 | 触屏设备上悬停态残留 |
这张表是我在排查导航状态问题时常用的对照清单，基本覆盖了绝大多数状态错乱的根因。
5.3 触屏设备上的悬停态陷阱
桌面端的下拉菜单通常靠 hover 触发，但触屏设备没有真正的 hover。很多项目在触屏上出现"点一下没反应、点两下才展开"或者"展开后收不起来"的问题，根源就是把 hover 当成了唯一的触发方式。
稳妥的做法是：hover 只作为桌面端的增强，真正的展开/收起逻辑绑定在点击事件上。同时用媒体查询@media (hover: hover)来判断设备是否支持真正的悬停，只在支持的设备上启用 hover 展开。这样触屏设备上就是纯粹的点击展开，行为可预期。
@media (hover: hover) and (pointer: fine) { .nav-item:hover .submenu { display: block; } }这段媒体查询是关键，它把 hover 行为限定在真正支持悬停的设备上，避免了触屏上的各种诡异表现。
6. 几个从实际项目里磨出来的经验
前面讲的都是结构和方法，这一节聊几个具体的、文档里不太会写但实际很影响体验的点。
第一个经验是关于导航项的文案长度。设计稿里的导航文案通常是两到四个字，但真实运营填进来的文案可能长得多。如果导航项没有设置最大宽度和溢出处理，长文案会把整个导航撑变形。我的做法是给导航项设一个合理的最大宽度，超出用省略号，同时用title属性或 tooltip 提供完整文案。这个处理看着不起眼，但能避免上线后被运营文案搞崩布局。
第二个经验是关于面包屑和导航的职责划分。很多人把面包屑当成导航的补充，其实两者职责不同：导航回答"能去哪"，面包屑回答"从哪来"。所以面包屑不应该承载跳转到其他栏目的功能，它只应该展示当前路径并支持逐级返回。把面包屑做成"第二个导航"，反而会让用户困惑。
第三个经验是关于导航的加载态。如果导航项是权限动态生成的（不同角色看到不同入口），那么在权限数据加载完成之前，导航应该显示骨架屏或者干脆不渲染，而不是先渲染一个空导航再突然填充。后者会导致布局跳动，用户刚想点某个位置，导航突然变了，点击落空。这个细节在权限复杂的后台系统里尤其重要。
第四个经验是关于当前项的滚动可见性。侧边导航很长时，用户通过外部链接直接进入一个靠下的三级页面，自动展开后当前项可能在可视区域之外。这时候应该主动把当前项滚动到可视区域内，让用户一眼看到自己在哪。用scrollIntoView({ block: 'nearest' })就能实现，成本极低但体验提升明显。
这些点单独看都很小，但导航作为高频组件，每一个小问题都会被放大到每一次使用中。把大结构做对，再把这些小细节磨平，导航才算真正"全面掌握"。
