做了好多年前端以后我发现自己对侧边栏的执念比想象中深。后台系统里真正影响日常体验的地方往往不是业务逻辑有多漂亮而是左侧那个导航栏用着顺不顺手。这次就围绕“二级菜单导航栏左侧”这个需求把数据模型、实现方案、交互状态和权限接入完整梳理一遍顺便聊聊我在项目里踩过的坑。如果你是刚接手后台系统的新手可以照着文章里的思路搭一套如果已经是老手也可以看看自己在高亮保持和动态菜单这两块有没有遗漏。1. 从布局习惯说起左侧二级菜单为什么会成为后台系统标配如果你翻过几十个后台系统会发现一个规律导航几乎都放在左侧层级深一点的还会做成二级菜单。这背后不完全是审美惯性更多是使用效率和历史习惯共同作用的结果。1.1 为什么是左侧而不是顶部先从一个反直觉的现象说起顶部导航在官网、内容站里很常见但到了业务后台几乎清一色换成左侧导航。原因主要有两个。第一是阅读扫描习惯。人眼扫视页面时视线通常从左上角开始沿着左侧边缘往下寻找信息。后台用户每天要高频切换页面左侧导航最容易被眼睛捕捉到不需要刻意寻找。顶部导航虽然也在视野范围内但当菜单项多了以后用户需要横向移动视线扫描成本明显更高。第二是空间利用方式不同。顶部导航的宽度受浏览器窗口限制一般只能放六到十个一级入口再多就要做下拉或横向滚动体验迅速劣化。左侧导航可以向下无限延伸天然适合承载多层级菜单。二级菜单在左侧展开时只是纵向多出一排文字不会挤压页面的主体内容区域如果放在顶部二级菜单通常要弹出浮层遮挡内容不说鼠标一移开就消失的交互也容易让人烦躁。另外还有一层历史因素。桌面软件时代资源管理器、各类开发工具都采用左侧树形导航用户对“左边是功能列表右边是工作区”的心智模型已经非常牢固。Web后台系统延续这套布局学习成本几乎为零。1.2 二级菜单要回答的三个核心问题说起来“做个左侧二级菜单”好像是个非常小的需求但它实际上要同时回答三个问题层级怎么呈现一级菜单和二级菜单之间是默认全部展开还是点击一级菜单才展开状态怎么保持用户当前停留在哪个页面导航要如何高亮刷新浏览器之后展开状态和高亮状态能不能还原权限怎么区分不同角色登录后看到的菜单不同前端要如何渲染出对应的二级菜单大多数项目里样式和动画反而是最简单的部分真正的复杂度全在这三件事上。我见过不少系统导航刚做出来时很清爽上线后天天收到“菜单展开状态不对”“刷新后高亮没了”“某人看不到某个二级菜单”之类的反馈追根到底都是这三个问题没想透。所以我建议每个接触后台开发的人先不要把“二级菜单”当成一个 CSS 任务而要当成一个“数据 状态 权限”的联动任务。后面的内容都会围绕这个思路展开。2. 先把菜单数据模型定清楚树形结构、排序和图标字段的设计我在重构一个后台导航栏时最耗时的不是写组件而是把菜单数据理清楚。一个项目经过多年迭代后菜单数据往往散落在各个接口和配置文件里有的模块从接口拿有的模块写死在静态文件里有的二级菜单甚至通过运营后台动态配置。这种情况下不管前端代码多优雅导航都会变得很难维护。2.1 树形结构使用嵌套children还是扁平列表要搭建左侧二级菜单第一件事是设计菜单的数据结构。目前主流有两种形式。一种是嵌套树形结构例如const menuData [ { id: dashboard, title: 工作台, icon: Home, path: /dashboard, children: [] }, { id: system, title: 系统管理, icon: Settings, path: /system, children: [ { id: user, title: 用户管理, icon: User, path: /system/user, children: [] }, { id: role, title: 角色管理, icon: UserFilled, path: /system/role, children: [] } ] } ]树形结构非常直观一眼就能看出层级关系前端渲染时递归遍历即可。缺陷是如果后端存储的是平铺数据组装树的时候需要额外写转换逻辑操作不慎还容易造成循环引用。另一种是扁平列表每条数据带parentIdconst menuData [ { id: 1, title: 工作台, path: /dashboard, parentId: 0, sort: 10 }, { id: 2, title: 系统管理, path: /system, parentId: 0, sort: 20 }, { id: 3, title: 用户管理, path: /system/user, parentId: 2, sort: 10 }, { id: 4, title: 角色管理, path: /system/role, parentId: 2, sort: 20 } ]扁平列表的好处是数据库落表方便权限过滤时只需要按id筛选排序也稳定。缺点是需要前端手动组装树。我的建议是接口给你什么你就接什么但前端内部统一处理成树形结构再交给导航组件渲染。这样无论后端数据结构怎么变导航组件只认一种输入不会被乱七八糟的字段带偏。2.2 排序、隐藏和图标字段不注意会在后期吃大亏菜单数据结构里有几个字段比想象中重要漏掉它们会埋下隐患。首先是sort排序字段。很多后台系统早期不设计排序接口直接按主键 ID 返回菜单看起来没问题。一旦运营需要调整菜单顺序数据库不能随便改 ID只能临时加字段反而要动底层表结构。正确的设计是预留sort并且数值之间留间隔比如 10、20、30方便后续插入新菜单时不用整体重排。其次是hidden字段。这个字段用来表示“菜单存在但不在导航中显示只能通过 URL 直达”。比如一些特殊页面、详情页、引导页都不该放在导航里但路由必须能访问。如果没有hidden开发者往往会硬着头皮把不需要展示的入口也塞进菜单导致侧边栏越来越长。第三是icon字段。图标在菜单里不只是装饰更是帮助用户快速识别功能区的重要视觉线索。设计时最好存图标名而不是存图片地址因为前端流行图标库会升级图片地址一变就裂。存图标名后前端用映射表统一转换成图标组件既灵活又可控。我见过一些项目为了省事把权限、隐藏、排序逻辑全部写在导航组件里数据模型不做区分。结果导航组件越来越胖改一次需求要动用全局搜索。先定清楚数据结构后面很多问题会自动消失。3. 二级菜单的三种实现路子纯CSS、JS点击、组件化选型对比数据模型定好之后就要决定用什么方式实现交互。我见过的常规方案有三种纯 CSS 展开、JS 点击控制、组件库方案。三者的适用场景差别很大选错会平白增加维护成本。3.1 纯CSS hover展开只适合轻量导航纯 CSS 实现通常是用:hover控制二级菜单的显示隐藏.menu-item:hover .sub-menu { display: block; }这种方案在官网导航、文档站里很常见因为这类站点菜单层级浅、交互简单而且主要是鼠标操作。但拿到后台系统里问题就会接踵而来。移动端没有 hover触屏设备上根本点不开二级菜单键盘用户无法通过 Tab 键展开子菜单不符合可访问性要求展开状态完全不受代码控制想做到“点击其他菜单时自动收起当前展开的菜单”只能依赖额外逻辑。后台系统普遍需要精确控制导航状态纯 CSS 方案可以说是天然乏力。3.2 JS点击控制展开收起后台管理系统最常用的方案后台项目里更通用的是用 JS 维护一个“展开菜单列表”。点击一级菜单时如果它没有子菜单就跳转路由如果有子菜单就切换展开状态。数据结构通常是一个数组或 SetopenKeys new Set([system, user])把这个 Set 存储在当前页面的状态管理里渲染时判断每个菜单是否在openKeys中从而决定二级菜单是否展开。这个方案最大的好处是状态可控可以配合路由高亮自动展开对应菜单也可以实现手风琴模式还可以把展开状态持久化到本地存储用户刷新后菜单也能保持原样。相比纯 CSS代码量多一些但可控性换来的是长期维护的省心。很多人在这里会犯一个经典的错误用单个布尔值控制所有菜单的展开与收起导致要么全部展开、要么全部收起无法精确控制某一个菜单。正确的思路一定是维护一个“当前展开菜单的集合”而不是一个开关。3.3 组件化方案与自研如何选现在主流组件库里都有现成的导航组件比如 Element 的el-menu、Naive UI 的n-menu、React 生态的antd Menu。如果你用的是现成组件库直接用就好省去很多基础交互代码。组件库的default-active和default-openeds对应高亮和展开状态基本都能满足常规需求。但组件库方案也有尴尬的地方定制性受限。比如你希望二级菜单的缩进距离更紧凑、需要支持拖拽排序、或者要融合一套全新的视觉风格改组件库的内部结构往往比自研还痛苦。另外有些组件库的导航默认行为是父级菜单只展开不跳转如果你希望父级菜单既能展开又能跳转到默认子页面就要自己处理额外逻辑。我的选型经验可以总结成下面这张表方案适用场景交互可控性维护成本纯 CSS hover官网、文档站、轻量导航低低JS 点击自研后台系统、需要精确控制状态高中组件库快速开发、视觉风格固定中中如果项目里后台业务复杂、权限模型要求高我倾向于自研一个轻量导航组件。如果只是快速交付一个内部工具直接用组件库足够没必要重复造轮子。4. 手写一套可落地的左侧二级菜单完整实现与关键代码讲了这么多还是要落到代码上。下面我用原生 HTML、CSS、JavaScript 实现一套最简可用的左侧二级菜单思路可以直接迁移到 Vue 或 React 项目里。4.1 HTML结构嵌套列表的语义化写法左侧菜单的本质是“树形列表”用ul和li嵌套是比较自然的语义化写法。一级菜单如果包含二级菜单就在该li内部再放一个ul。这样不仅结构清晰样式上也容易做层级缩进。nav classside-menu ul classmenu-list li classmenu-item button classmenu-title>.side-menu { width: 220px; border-right: 1px solid #e5e7eb; overflow-x: hidden; overflow-y: auto; } .menu-list { list-style: none; margin: 0; padding: 8px; } .menu-title { display: block; width: 100%; padding: 10px 12px; background: transparent; border: none; cursor: pointer; text-align: left; font-size: 14px; color: #333; border-radius: 6px; } .menu-title:hover { background: #f3f4f6; } .sub-menu { overflow: hidden; max-height: 0; padding-left: 16px; transition: max-height 0.25s ease; } .sub-menu.open { max-height: 200px; } .sub-menu a { display: block; padding: 8px 12px; font-size: 13px; color: #666; text-decoration: none; border-radius: 6px; } .sub-menu a.active { background: #ecf5ff; color: #2d6cdf; }max-height方案有一个问题如果你设定的max-height值小于实际菜单高度动画会截断值太大展开速度又显得不自然。于是很多人会采用grid-template-rows: 0fr到1fr的过渡它能精确跟随内容高度实现类似展开/收起的效果.sub-menu { display: grid; grid-template-rows: 0fr; transition: grid-template-rows 0.25s ease; } .sub-menu.open { grid-template-rows: 1fr; } .sub-menu ul { overflow: hidden; }这两种方案我都用过实际项目中grid-template-rows的体验更好不需要估算高度也不用担心菜单项增减导致动画截断。4.3 交互逻辑点击、高亮和路由同步原生 JavaScript 逻辑其实很简单维护一个openKeys集合点击一级菜单时切换对应 key 在集合中的状态然后重新给每个二级菜单容器加/删 class。const openKeys new Set(); document.querySelectorAll(.menu-title).forEach((titleBtn) { titleBtn.addEventListener(click, () { const key titleBtn.dataset.key; const subMenu titleBtn.nextElementSibling; if (openKeys.has(key)) { openKeys.delete(key); subMenu.classList.remove(open); } else { openKeys.add(key); subMenu.classList.add(open); } }); });这个基础版本的交互在简单场景下够用但拿到真实后台项目里还需要补充两块逻辑。第一块是路由高亮。菜单里的链接被点击后浏览器 URL 变了导航组件必须知道“当前路径对应哪个菜单项”从而在对应链接上加上.active高亮类。原生实现通常是在window.addEventListener(hashchange 或popstate 事件里重新计算当前路径然后遍历所有菜单链接找到 path 匹配的那一项。第二块是持久化。希望用户刷新后菜单还保持展开状态可以在点击展开时把openKeys存入localStorage初始化菜单时读取并还原。这一点在纯前端方案里很容易实现后面我会进一步展开。5. 高亮保持、展开冲突与路由联动最容易翻车的三个坑菜单写起来很简单但大部分后台系统的导航问题都出在三个特定场景刷新之后状态丢失、多个菜单同时展开导致界面混乱、路由和菜单状态不同步。下面逐个拆解。5.1 刷新后高亮丢失从路由反推展开链很多开发者做高亮的方式是“点谁给谁加 active”这样刷新页面后 active 就丢了。因为用户可能在地址栏直接输入某个子页面 URL也可能从通知消息里跳转到某个二级页面根本不会经过菜单点击。正确做法是每次路由变化后用当前路径去菜单树里匹配找到对应菜单项然后把它的所有祖先节点都展开再高亮当前项。这需要一个“根据路径查询菜单祖先链”的工具函数function findMenuChain(menus, targetPath, chain []) { for (const menu of menus) { const nextChain [...chain, menu.id]; if (menu.path targetPath) { return nextChain; } if (menu.children menu.children.length) { const result findMenuChain(menu.children, targetPath, nextChain); if (result) { return result; } } } return null; }拿到chain后把链上的所有菜单 id 加入openKeys把最后一个菜单项标记为 active。这套逻辑放在路由变化后的统一处理函数里而不是分散在各处的点击事件中才能保证任何入口跳转都能正确还原导航状态。需要注意处理路径匹配的边界情况比如/system/user和/system/user/1可能对应同一个菜单详情页匹配时可能需要按前缀匹配而不是严格相等。引入路由表里的name字段来匹配通常更可靠因为 URL 可能带参数name是稳定标识。5.2 展开冲突手风琴效果还是多开并存后台导航有两种常见交互模式手风琴模式和自由展开模式。手风琴模式指同一时间只保留一个一级菜单是展开状态。优点是界面干净不会出现大片菜单铺满侧边栏的情况缺点是用户在一个模块下展开过二级菜单后切换到另一个模块时原来的展开区域会自动收起操作上可能多一步。自由展开模式则允许多个一级菜单同时展开。用户可以在不同模块之间切换时保留各自的展开状态减少重复打开的操作但菜单一多界面会显得拥挤。从技术上看两者的区别只在于处理openKeys时是否做互斥。手风琴模式在添加新 key 时清空除它之外的所有 key自由展开模式则是简单往里添加。我的建议是小团队内部系统用自由展开因为用户通常需要在多个模块间来回切换保留展开状态更高效面向客户的大系统用默认手风琴避免不熟悉系统的用户被一屏密密麻麻的菜单吓到。如果预算允许做成“展开模式”配置项让用户自己选择就更完善了。5.3 路由跳转与菜单联动的时序问题还有一个典型问题路由已经跳转成功了但菜单没有同步展开。比如用户从工作台通过全局搜索直接跳到/system/user此时 URL 已经是用户管理了但左侧导航还是收起状态。这是因为你只把路由变化后的处理逻辑绑定在了菜单点击事件上没有监听路由本身的变化。正确做法是在应用层统一监听路由变化每次变化后重新执行“反推展开链”和“高亮”操作。不要依赖菜单点击事件去设置高亮菜单点击只是触发路由变化的一种方式导航高亮必须落在路由层否则永远会出现不同步的漏网之鱼。我参与的一个后台项目就因为这个时序问题反复被提缺陷最后我们把所有导航状态更新逻辑收敛到一个函数里并且只在路由变化时调用菜单本身只负责触发跳转职责分离之后问题彻底消失。6. 权限控制与动态菜单接口返回的数据如何映射成导航到了这一层菜单已经不只是前端组件的事它和权限系统深度耦合。常见的业务是不同角色登录后侧边栏菜单完全不同。这个功能做不好轻则用户看到不该有的入口重则绕过前端直接访问无权限的页面。6.1 权限菜单体系的基本设计相对推荐的方案是后端负责过滤前端只负责渲染。用户登录成功后后端返回一个已经经过权限过滤的菜单列表前端把这个列表存到全局状态里驱动导航渲染。流程大致是用户登录拿到身份标识。前端请求“当前用户菜单接口”。后端根据该用户的角色、权限点从完整菜单表中筛选出有权访问的树形结构并返回。前端把返回的菜单数据渲染成左侧导航同时动态注册对应路由。前端路由守卫里再做一次兜底判断防止用户手动输入 URL 访问无权限页面。这样的好处是权限规则集中在后端管理不会因为前端代码被篡改而泄露权限。很多公司为了防止安全问题会在菜单表里同时存“菜单标识”和“接口权限”前端无权接口时后端也会拒绝但菜单显隐仍然以前端渲染为准。6.2 动态菜单渲染后的路由注册与刷新处理动态菜单真正的坑在“刷新”。如果路由是登录后根据菜单动态注册的刷新页面时全局状态里的菜单数据会被清空路由自然也没有注册。此时用户明明已经登录了刷新一下却显示 404 或者空白页。解决思路是在应用初始化时或者路由守卫的某个阶段先检查全局状态里有没有菜单数据没有就重新拉取菜单接口、重新注册路由。用 Vue 项目举例核心流程类似router.beforeEach(async (to, from, next) { const menus store.state.menus; if (!menus.length) { const data await fetchUserMenus(); store.commit(setMenus, data); // 这里根据 data 动态 addRoute next({ ...to, replace: true }); } else { next(); } });React 项目里类似在路由组件的初始化阶段异步获取菜单渲染期间显示加载态。这里有一个细节初始路由若配置成/跳转到第一个合法菜单需要等菜单数据加载完再决定跳转目标否则会跳到默认首页导致用户看到无权限页面。6.3 图标映射和菜单排序两个容易忽略的小雷动态菜单的后端返回数据里图标通常是字符串比如icon-user。前端不能直接把这个字符串塞进 HTML 或者当作组件名动态解析这样既慢又不安全。推荐做法是维护一个图标映射表把接口返回的字符串映射成真正的图标组件const iconMap { icon-home: HomeIcon, icon-user: UserIcon, icon-settings: SettingsIcon, // 其他图标 }; function resolveIcon(name) { return iconMap[name] || DefaultIcon; }这样做的另一个好处是后端图标名变了前端只需要在映射表里调整不用改菜单数据。排序问题则要记住一条原则前端不要擅自重排菜单顺序后端接口返回的顺序就是展示顺序。如果某些菜单需要调整位置应该让后端修改sort字段而不是前端写一堆filter和sort逻辑。因为菜单顺序同时影响导航显示和移动端的菜单排列前端排得再好和数据库里其他业务逻辑不一致迟早会对不上账。我在实际项目里见过太多次“前端写好排序运营后台改了菜单顺序后前端不生效”的案例最后都要回过头来规范数据源头。做任何一个后台系统左侧二级菜单导航栏都是绕不开的基建环节。我的个人经验是把菜单数据模型当一等公民来设计把路由高亮和展开状态的同步逻辑收敛到一个统一入口权限过滤交给后端处理。这三条做好了导航栏就不会成为你长期维护的痛点。 
长河君 · 2026/10/17 22:23:08 · 阅读 1.2k 后台系统左侧二级菜单导航：数据模型、状态同步与权限接入实践
做了好多年前端以后我发现自己对侧边栏的执念比想象中深。后台系统里真正影响日常体验的地方往往不是业务逻辑有多漂亮而是左侧那个导航栏用着顺不顺手。这次就围绕“二级菜单导航栏左侧”这个需求把数据模型、实现方案、交互状态和权限接入完整梳理一遍顺便聊聊我在项目里踩过的坑。如果你是刚接手后台系统的新手可以照着文章里的思路搭一套如果已经是老手也可以看看自己在高亮保持和动态菜单这两块有没有遗漏。1. 从布局习惯说起左侧二级菜单为什么会成为后台系统标配如果你翻过几十个后台系统会发现一个规律导航几乎都放在左侧层级深一点的还会做成二级菜单。这背后不完全是审美惯性更多是使用效率和历史习惯共同作用的结果。1.1 为什么是左侧而不是顶部先从一个反直觉的现象说起顶部导航在官网、内容站里很常见但到了业务后台几乎清一色换成左侧导航。原因主要有两个。第一是阅读扫描习惯。人眼扫视页面时视线通常从左上角开始沿着左侧边缘往下寻找信息。后台用户每天要高频切换页面左侧导航最容易被眼睛捕捉到不需要刻意寻找。顶部导航虽然也在视野范围内但当菜单项多了以后用户需要横向移动视线扫描成本明显更高。第二是空间利用方式不同。顶部导航的宽度受浏览器窗口限制一般只能放六到十个一级入口再多就要做下拉或横向滚动体验迅速劣化。左侧导航可以向下无限延伸天然适合承载多层级菜单。二级菜单在左侧展开时只是纵向多出一排文字不会挤压页面的主体内容区域如果放在顶部二级菜单通常要弹出浮层遮挡内容不说鼠标一移开就消失的交互也容易让人烦躁。另外还有一层历史因素。桌面软件时代资源管理器、各类开发工具都采用左侧树形导航用户对“左边是功能列表右边是工作区”的心智模型已经非常牢固。Web后台系统延续这套布局学习成本几乎为零。1.2 二级菜单要回答的三个核心问题说起来“做个左侧二级菜单”好像是个非常小的需求但它实际上要同时回答三个问题层级怎么呈现一级菜单和二级菜单之间是默认全部展开还是点击一级菜单才展开状态怎么保持用户当前停留在哪个页面导航要如何高亮刷新浏览器之后展开状态和高亮状态能不能还原权限怎么区分不同角色登录后看到的菜单不同前端要如何渲染出对应的二级菜单大多数项目里样式和动画反而是最简单的部分真正的复杂度全在这三件事上。我见过不少系统导航刚做出来时很清爽上线后天天收到“菜单展开状态不对”“刷新后高亮没了”“某人看不到某个二级菜单”之类的反馈追根到底都是这三个问题没想透。所以我建议每个接触后台开发的人先不要把“二级菜单”当成一个 CSS 任务而要当成一个“数据 状态 权限”的联动任务。后面的内容都会围绕这个思路展开。2. 先把菜单数据模型定清楚树形结构、排序和图标字段的设计我在重构一个后台导航栏时最耗时的不是写组件而是把菜单数据理清楚。一个项目经过多年迭代后菜单数据往往散落在各个接口和配置文件里有的模块从接口拿有的模块写死在静态文件里有的二级菜单甚至通过运营后台动态配置。这种情况下不管前端代码多优雅导航都会变得很难维护。2.1 树形结构使用嵌套children还是扁平列表要搭建左侧二级菜单第一件事是设计菜单的数据结构。目前主流有两种形式。一种是嵌套树形结构例如const menuData [ { id: dashboard, title: 工作台, icon: Home, path: /dashboard, children: [] }, { id: system, title: 系统管理, icon: Settings, path: /system, children: [ { id: user, title: 用户管理, icon: User, path: /system/user, children: [] }, { id: role, title: 角色管理, icon: UserFilled, path: /system/role, children: [] } ] } ]树形结构非常直观一眼就能看出层级关系前端渲染时递归遍历即可。缺陷是如果后端存储的是平铺数据组装树的时候需要额外写转换逻辑操作不慎还容易造成循环引用。另一种是扁平列表每条数据带parentIdconst menuData [ { id: 1, title: 工作台, path: /dashboard, parentId: 0, sort: 10 }, { id: 2, title: 系统管理, path: /system, parentId: 0, sort: 20 }, { id: 3, title: 用户管理, path: /system/user, parentId: 2, sort: 10 }, { id: 4, title: 角色管理, path: /system/role, parentId: 2, sort: 20 } ]扁平列表的好处是数据库落表方便权限过滤时只需要按id筛选排序也稳定。缺点是需要前端手动组装树。我的建议是接口给你什么你就接什么但前端内部统一处理成树形结构再交给导航组件渲染。这样无论后端数据结构怎么变导航组件只认一种输入不会被乱七八糟的字段带偏。2.2 排序、隐藏和图标字段不注意会在后期吃大亏菜单数据结构里有几个字段比想象中重要漏掉它们会埋下隐患。首先是sort排序字段。很多后台系统早期不设计排序接口直接按主键 ID 返回菜单看起来没问题。一旦运营需要调整菜单顺序数据库不能随便改 ID只能临时加字段反而要动底层表结构。正确的设计是预留sort并且数值之间留间隔比如 10、20、30方便后续插入新菜单时不用整体重排。其次是hidden字段。这个字段用来表示“菜单存在但不在导航中显示只能通过 URL 直达”。比如一些特殊页面、详情页、引导页都不该放在导航里但路由必须能访问。如果没有hidden开发者往往会硬着头皮把不需要展示的入口也塞进菜单导致侧边栏越来越长。第三是icon字段。图标在菜单里不只是装饰更是帮助用户快速识别功能区的重要视觉线索。设计时最好存图标名而不是存图片地址因为前端流行图标库会升级图片地址一变就裂。存图标名后前端用映射表统一转换成图标组件既灵活又可控。我见过一些项目为了省事把权限、隐藏、排序逻辑全部写在导航组件里数据模型不做区分。结果导航组件越来越胖改一次需求要动用全局搜索。先定清楚数据结构后面很多问题会自动消失。3. 二级菜单的三种实现路子纯CSS、JS点击、组件化选型对比数据模型定好之后就要决定用什么方式实现交互。我见过的常规方案有三种纯 CSS 展开、JS 点击控制、组件库方案。三者的适用场景差别很大选错会平白增加维护成本。3.1 纯CSS hover展开只适合轻量导航纯 CSS 实现通常是用:hover控制二级菜单的显示隐藏.menu-item:hover .sub-menu { display: block; }这种方案在官网导航、文档站里很常见因为这类站点菜单层级浅、交互简单而且主要是鼠标操作。但拿到后台系统里问题就会接踵而来。移动端没有 hover触屏设备上根本点不开二级菜单键盘用户无法通过 Tab 键展开子菜单不符合可访问性要求展开状态完全不受代码控制想做到“点击其他菜单时自动收起当前展开的菜单”只能依赖额外逻辑。后台系统普遍需要精确控制导航状态纯 CSS 方案可以说是天然乏力。3.2 JS点击控制展开收起后台管理系统最常用的方案后台项目里更通用的是用 JS 维护一个“展开菜单列表”。点击一级菜单时如果它没有子菜单就跳转路由如果有子菜单就切换展开状态。数据结构通常是一个数组或 SetopenKeys new Set([system, user])把这个 Set 存储在当前页面的状态管理里渲染时判断每个菜单是否在openKeys中从而决定二级菜单是否展开。这个方案最大的好处是状态可控可以配合路由高亮自动展开对应菜单也可以实现手风琴模式还可以把展开状态持久化到本地存储用户刷新后菜单也能保持原样。相比纯 CSS代码量多一些但可控性换来的是长期维护的省心。很多人在这里会犯一个经典的错误用单个布尔值控制所有菜单的展开与收起导致要么全部展开、要么全部收起无法精确控制某一个菜单。正确的思路一定是维护一个“当前展开菜单的集合”而不是一个开关。3.3 组件化方案与自研如何选现在主流组件库里都有现成的导航组件比如 Element 的el-menu、Naive UI 的n-menu、React 生态的antd Menu。如果你用的是现成组件库直接用就好省去很多基础交互代码。组件库的default-active和default-openeds对应高亮和展开状态基本都能满足常规需求。但组件库方案也有尴尬的地方定制性受限。比如你希望二级菜单的缩进距离更紧凑、需要支持拖拽排序、或者要融合一套全新的视觉风格改组件库的内部结构往往比自研还痛苦。另外有些组件库的导航默认行为是父级菜单只展开不跳转如果你希望父级菜单既能展开又能跳转到默认子页面就要自己处理额外逻辑。我的选型经验可以总结成下面这张表方案适用场景交互可控性维护成本纯 CSS hover官网、文档站、轻量导航低低JS 点击自研后台系统、需要精确控制状态高中组件库快速开发、视觉风格固定中中如果项目里后台业务复杂、权限模型要求高我倾向于自研一个轻量导航组件。如果只是快速交付一个内部工具直接用组件库足够没必要重复造轮子。4. 手写一套可落地的左侧二级菜单完整实现与关键代码讲了这么多还是要落到代码上。下面我用原生 HTML、CSS、JavaScript 实现一套最简可用的左侧二级菜单思路可以直接迁移到 Vue 或 React 项目里。4.1 HTML结构嵌套列表的语义化写法左侧菜单的本质是“树形列表”用ul和li嵌套是比较自然的语义化写法。一级菜单如果包含二级菜单就在该li内部再放一个ul。这样不仅结构清晰样式上也容易做层级缩进。nav classside-menu ul classmenu-list li classmenu-item button classmenu-title>.side-menu { width: 220px; border-right: 1px solid #e5e7eb; overflow-x: hidden; overflow-y: auto; } .menu-list { list-style: none; margin: 0; padding: 8px; } .menu-title { display: block; width: 100%; padding: 10px 12px; background: transparent; border: none; cursor: pointer; text-align: left; font-size: 14px; color: #333; border-radius: 6px; } .menu-title:hover { background: #f3f4f6; } .sub-menu { overflow: hidden; max-height: 0; padding-left: 16px; transition: max-height 0.25s ease; } .sub-menu.open { max-height: 200px; } .sub-menu a { display: block; padding: 8px 12px; font-size: 13px; color: #666; text-decoration: none; border-radius: 6px; } .sub-menu a.active { background: #ecf5ff; color: #2d6cdf; }max-height方案有一个问题如果你设定的max-height值小于实际菜单高度动画会截断值太大展开速度又显得不自然。于是很多人会采用grid-template-rows: 0fr到1fr的过渡它能精确跟随内容高度实现类似展开/收起的效果.sub-menu { display: grid; grid-template-rows: 0fr; transition: grid-template-rows 0.25s ease; } .sub-menu.open { grid-template-rows: 1fr; } .sub-menu ul { overflow: hidden; }这两种方案我都用过实际项目中grid-template-rows的体验更好不需要估算高度也不用担心菜单项增减导致动画截断。4.3 交互逻辑点击、高亮和路由同步原生 JavaScript 逻辑其实很简单维护一个openKeys集合点击一级菜单时切换对应 key 在集合中的状态然后重新给每个二级菜单容器加/删 class。const openKeys new Set(); document.querySelectorAll(.menu-title).forEach((titleBtn) { titleBtn.addEventListener(click, () { const key titleBtn.dataset.key; const subMenu titleBtn.nextElementSibling; if (openKeys.has(key)) { openKeys.delete(key); subMenu.classList.remove(open); } else { openKeys.add(key); subMenu.classList.add(open); } }); });这个基础版本的交互在简单场景下够用但拿到真实后台项目里还需要补充两块逻辑。第一块是路由高亮。菜单里的链接被点击后浏览器 URL 变了导航组件必须知道“当前路径对应哪个菜单项”从而在对应链接上加上.active高亮类。原生实现通常是在window.addEventListener(hashchange 或popstate 事件里重新计算当前路径然后遍历所有菜单链接找到 path 匹配的那一项。第二块是持久化。希望用户刷新后菜单还保持展开状态可以在点击展开时把openKeys存入localStorage初始化菜单时读取并还原。这一点在纯前端方案里很容易实现后面我会进一步展开。5. 高亮保持、展开冲突与路由联动最容易翻车的三个坑菜单写起来很简单但大部分后台系统的导航问题都出在三个特定场景刷新之后状态丢失、多个菜单同时展开导致界面混乱、路由和菜单状态不同步。下面逐个拆解。5.1 刷新后高亮丢失从路由反推展开链很多开发者做高亮的方式是“点谁给谁加 active”这样刷新页面后 active 就丢了。因为用户可能在地址栏直接输入某个子页面 URL也可能从通知消息里跳转到某个二级页面根本不会经过菜单点击。正确做法是每次路由变化后用当前路径去菜单树里匹配找到对应菜单项然后把它的所有祖先节点都展开再高亮当前项。这需要一个“根据路径查询菜单祖先链”的工具函数function findMenuChain(menus, targetPath, chain []) { for (const menu of menus) { const nextChain [...chain, menu.id]; if (menu.path targetPath) { return nextChain; } if (menu.children menu.children.length) { const result findMenuChain(menu.children, targetPath, nextChain); if (result) { return result; } } } return null; }拿到chain后把链上的所有菜单 id 加入openKeys把最后一个菜单项标记为 active。这套逻辑放在路由变化后的统一处理函数里而不是分散在各处的点击事件中才能保证任何入口跳转都能正确还原导航状态。需要注意处理路径匹配的边界情况比如/system/user和/system/user/1可能对应同一个菜单详情页匹配时可能需要按前缀匹配而不是严格相等。引入路由表里的name字段来匹配通常更可靠因为 URL 可能带参数name是稳定标识。5.2 展开冲突手风琴效果还是多开并存后台导航有两种常见交互模式手风琴模式和自由展开模式。手风琴模式指同一时间只保留一个一级菜单是展开状态。优点是界面干净不会出现大片菜单铺满侧边栏的情况缺点是用户在一个模块下展开过二级菜单后切换到另一个模块时原来的展开区域会自动收起操作上可能多一步。自由展开模式则允许多个一级菜单同时展开。用户可以在不同模块之间切换时保留各自的展开状态减少重复打开的操作但菜单一多界面会显得拥挤。从技术上看两者的区别只在于处理openKeys时是否做互斥。手风琴模式在添加新 key 时清空除它之外的所有 key自由展开模式则是简单往里添加。我的建议是小团队内部系统用自由展开因为用户通常需要在多个模块间来回切换保留展开状态更高效面向客户的大系统用默认手风琴避免不熟悉系统的用户被一屏密密麻麻的菜单吓到。如果预算允许做成“展开模式”配置项让用户自己选择就更完善了。5.3 路由跳转与菜单联动的时序问题还有一个典型问题路由已经跳转成功了但菜单没有同步展开。比如用户从工作台通过全局搜索直接跳到/system/user此时 URL 已经是用户管理了但左侧导航还是收起状态。这是因为你只把路由变化后的处理逻辑绑定在了菜单点击事件上没有监听路由本身的变化。正确做法是在应用层统一监听路由变化每次变化后重新执行“反推展开链”和“高亮”操作。不要依赖菜单点击事件去设置高亮菜单点击只是触发路由变化的一种方式导航高亮必须落在路由层否则永远会出现不同步的漏网之鱼。我参与的一个后台项目就因为这个时序问题反复被提缺陷最后我们把所有导航状态更新逻辑收敛到一个函数里并且只在路由变化时调用菜单本身只负责触发跳转职责分离之后问题彻底消失。6. 权限控制与动态菜单接口返回的数据如何映射成导航到了这一层菜单已经不只是前端组件的事它和权限系统深度耦合。常见的业务是不同角色登录后侧边栏菜单完全不同。这个功能做不好轻则用户看到不该有的入口重则绕过前端直接访问无权限的页面。6.1 权限菜单体系的基本设计相对推荐的方案是后端负责过滤前端只负责渲染。用户登录成功后后端返回一个已经经过权限过滤的菜单列表前端把这个列表存到全局状态里驱动导航渲染。流程大致是用户登录拿到身份标识。前端请求“当前用户菜单接口”。后端根据该用户的角色、权限点从完整菜单表中筛选出有权访问的树形结构并返回。前端把返回的菜单数据渲染成左侧导航同时动态注册对应路由。前端路由守卫里再做一次兜底判断防止用户手动输入 URL 访问无权限页面。这样的好处是权限规则集中在后端管理不会因为前端代码被篡改而泄露权限。很多公司为了防止安全问题会在菜单表里同时存“菜单标识”和“接口权限”前端无权接口时后端也会拒绝但菜单显隐仍然以前端渲染为准。6.2 动态菜单渲染后的路由注册与刷新处理动态菜单真正的坑在“刷新”。如果路由是登录后根据菜单动态注册的刷新页面时全局状态里的菜单数据会被清空路由自然也没有注册。此时用户明明已经登录了刷新一下却显示 404 或者空白页。解决思路是在应用初始化时或者路由守卫的某个阶段先检查全局状态里有没有菜单数据没有就重新拉取菜单接口、重新注册路由。用 Vue 项目举例核心流程类似router.beforeEach(async (to, from, next) { const menus store.state.menus; if (!menus.length) { const data await fetchUserMenus(); store.commit(setMenus, data); // 这里根据 data 动态 addRoute next({ ...to, replace: true }); } else { next(); } });React 项目里类似在路由组件的初始化阶段异步获取菜单渲染期间显示加载态。这里有一个细节初始路由若配置成/跳转到第一个合法菜单需要等菜单数据加载完再决定跳转目标否则会跳到默认首页导致用户看到无权限页面。6.3 图标映射和菜单排序两个容易忽略的小雷动态菜单的后端返回数据里图标通常是字符串比如icon-user。前端不能直接把这个字符串塞进 HTML 或者当作组件名动态解析这样既慢又不安全。推荐做法是维护一个图标映射表把接口返回的字符串映射成真正的图标组件const iconMap { icon-home: HomeIcon, icon-user: UserIcon, icon-settings: SettingsIcon, // 其他图标 }; function resolveIcon(name) { return iconMap[name] || DefaultIcon; }这样做的另一个好处是后端图标名变了前端只需要在映射表里调整不用改菜单数据。排序问题则要记住一条原则前端不要擅自重排菜单顺序后端接口返回的顺序就是展示顺序。如果某些菜单需要调整位置应该让后端修改sort字段而不是前端写一堆filter和sort逻辑。因为菜单顺序同时影响导航显示和移动端的菜单排列前端排得再好和数据库里其他业务逻辑不一致迟早会对不上账。我在实际项目里见过太多次“前端写好排序运营后台改了菜单顺序后前端不生效”的案例最后都要回过头来规范数据源头。做任何一个后台系统左侧二级菜单导航栏都是绕不开的基建环节。我的个人经验是把菜单数据模型当一等公民来设计把路由高亮和展开状态的同步逻辑收敛到一个统一入口权限过滤交给后端处理。这三条做好了导航栏就不会成为你长期维护的痛点。