真正可配置、可权限控制、支持增删改的左侧菜单必须依赖JavaScript动态操作DOM并结合后端API返回结构化数据，纯HTML无法实现；菜单数据来源决定逻辑复杂度：localStorage适合本地调试但不适用于生产，JSON文件需服务支持，生产环境必须通过API（如GET /api/menus）获取扁平或嵌套菜单数据；权限校验必须由后端按角色返回对应菜单项，前端仅负责渲染，不可仅靠隐藏DOM实现安全控制。
纯 HTML 文件无法“管理”菜单，只能渲染；真正可配置、可权限控制、支持增删改的左侧菜单，必须靠 JavaScript 动态操作 DOM + 后端 API 返回结构化数据。写死 <ul><li> 的页面，改个菜单名就得打开 HTML 手动编辑，不是后台，是幻灯片。
菜单数据从哪来：localStorage / JSON 文件 / API？
前端菜单内容不能凭空出现，来源决定你后续所有逻辑的复杂度：
-
localStorage适合本地调试：用JSON.stringify(menuItems)存数组，刷新不丢，但无法多人共享，上线即失效 - 读取本地
menu.json需起服务（npx serve），否则file://协议下fetch('/menu.json')直接被浏览器跨域拦截 - 生产环境必须走后端 API，如
GET /api/menus，返回带id、name、url、parent_id的扁平数组；增删改用POST/PUT/DELETE
菜单结构怎么组织：扁平数组还是嵌套树？
后端返回格式直接影响前端渲染方式和维护成本：
- 扁平数组（含
parent_id）更利于数据库存储和更新，前端需用Map或递归构建树，例如：const menuItems = [<br> { id: 1, name: "系统设置", parent_id: null },<br> { id: 2, name: "用户管理", parent_id: 1 },<br> { id: 3, name: "角色管理", parent_id: 1 }<br>]; - 嵌套树（含
children字段）省去前端组装步骤，但修改子项时容易漏更新深层节点，深拷贝或路径定位成本高 - 一级和二级菜单混在同一个
<ul>里，靠class="submenu"控制显隐，比用多个<iframe>更可控、SEO 友好、无 iframe 跨域/性能问题
点击跳转怎么处理：避免整页刷新又同步 URL？
现代后台菜单不 reload 整页，但 URL 必须可 bookmark 和前进/后退：
立即学习“前端免费学习笔记（深入）”；
- 禁用
href="#"—— 它会滚到页面顶部；改用href="javascript:void(0)"或直接绑定onclick - 拦截默认行为：
event.preventDefault()，再用fetch加载内容到<div id="content"> - URL 同步靠
history.pushState({ path }, "", url)，监听popstate处理浏览器后退/前进 - 外链必须加
target="_blank" rel="noopener"，否则有安全风险（window.opener 泄露）
为什么不用 <frameset> 或 <iframe>？
这两个标签已被 HTML5 废弃，且在实际后台开发中带来明确缺陷：
-
<frameset>在所有现代浏览器中已完全不支持，HTML 解析器直接忽略，连样式都挂不上 -
<iframe>导致父子页面跨域通信困难，CSS 样式隔离、JS 上下文隔离、SEO 不可见、内存泄漏风险高 - 主流框架（Vue/React）和后台模板（Ant Design Pro、Vue Element Admin）全部采用单容器 + JS 渲染，
<iframe>是历史包袱，不是解决方案
最易被忽略的一点：菜单权限不是靠前端隐藏 <li> 实现的——后端 API 必须按角色返回对应菜单项，否则用户只要打开 DevTools 修改 localStorage 或伪造请求，就能看到并访问未授权菜单。前端渲染只是展示层，权限校验永远发生在服务端。
