纯HTML无法实现真正的后台菜单管理，仅能静态渲染；必须依赖JS操作DOM或对接后端API获取动态菜单数据，通过扁平数组或嵌套树结构渲染，并用history.pushState同步URL，禁用已废弃的<frameset>。
纯 HTML 无法实现真正的“后台菜单管理”——它没有数据持久化、权限校验或服务端逻辑能力，只能做静态结构渲染和前端交互模拟。 所有“可配置”“可增删”的效果，都依赖 JavaScript 操作 DOM 或对接后端 API。直接写死 <ul><li> 标签堆出来的菜单，不是管理，只是展示。
菜单数据从哪来：localStorage / JSON 文件 / API？
前端菜单内容必须有来源，否则改个名字就得手动改 HTML 文件，根本谈不上“管理”。
-
localStorage适合开发调试：用JSON.stringify()存菜单数组，刷新不丢，但多人协作或部署后无法共享 - 本地
menu.json文件可通过fetch('/menu.json')加载，但需服务器支持静态文件访问，且无法写入（只读） - 真实场景必须走后端 API，如
GET /api/menus返回带id、name、url、parent_id的树形结构；增删改需POST/PUT/DELETE - 注意：若用
file://协议直接双击打开 HTML，fetch会因跨域被浏览器拦截，必须起本地服务（如npx serve）
菜单结构怎么组织：扁平数组还是嵌套树？
后端返回的数据结构直接影响前端渲染逻辑。常见两种方式：
- 扁平数组（含
parent_id）：更易存储和更新，前端需用递归或Map构建树，例如：const menuItems = [ { id: 1, name: "用户管理", parent_id: null }, { id: 2, name: "新增用户", parent_id: 1 }, { id: 3, name: "角色管理", parent_id: null } ]; - 嵌套树（children 字段）：后端已处理好层级，前端可直接
renderMenu(menuData)递归渲染，但修改子项时需深拷贝或路径定位，容易漏更新 - 一级菜单和二级菜单混在同一个
<ul>里，靠class="submenu"控制显隐，比用多个独立<iframe>或<frameset>更现代、可控、SEO 友好
点击跳转怎么处理：target="_self" 还是 JS 路由？
传统 <a href="user-list.html" target="main"> 依赖 <frame> 或 iframe，现在基本淘汰。现代做法是：
立即学习“前端免费学习笔记（深入）”；
- 用
event.preventDefault()拦截默认跳转，再用fetch加载内容到<div id="content">，避免整页刷新 - URL 地址栏同步更新用
history.pushState()，配合popstate监听浏览器前进/后退 - 不要给菜单项写死
href="#"，它会跳到页面顶部；改用href="javascript:void(0)"或直接绑定onclick - 如果真要开新页（如外链文档），明确加
target="_blank" rel="noopener"防安全风险
为什么不能用 <frameset> 做菜单管理？
<frameset> 是 HTML4 的废弃标签，HTML5 已移除，Chrome/Firefox 等现代浏览器虽暂未完全禁用，但存在严重问题：
- 无法响应式：
rows/cols是固定像素或百分比，缩放或小屏下极易错位 - SEO 不友好：搜索引擎难以合并多个 frame 页面的内容权重
- 状态丢失：刷新后所有 frame 回到初始 URL，无法保留用户当前操作页
- 调试困难：每个 frame 是独立上下文，
console.log、断点、网络请求分散在不同面板 - 替代方案就是 CSS Flex/Grid + JS 动态内容区，代码量相当，但可控性、可维护性高一个数量级
真正难的从来不是写几个 <li>，而是让菜单能随权限动态收拢、支持拖拽排序、记录用户最近访问项、与后端菜单树实时同步——这些都得绕过 HTML 的静态本质，靠 JS 和服务端协同完成。
