浏览器不支持网页内原生收藏，需用localStorage结构化存储收藏项（含id、title、url、timestamp），防重复添加，读-改-写避免多标签页丢失，并渲染为可跳转、可删除的DOM菜单。
浏览器原生不提供「网页内菜单收藏」功能，所谓“HTML 做菜单收藏”，本质是前端用 JavaScript 模拟收藏行为，把用户点击的链接或页面标题存到 localStorage 或 sessionStorage 里，再渲染成可交互的列表。没有服务器参与、不涉及后端存储，纯客户端实现。
怎么用 localStorage 实现持久化菜单收藏
这是最常用也最稳妥的方式：关掉浏览器再打开，收藏项还在。关键点不是“存”，而是“怎么结构化存”和“怎么避免重复”。
-
localStorage只接受字符串，必须用JSON.stringify()存、JSON.parse()读 - 每条收藏建议用对象表示：
{ id: Date.now(), title: "GitHub", url: "https://github.com", timestamp: Date.now() }，id用于去重和删除，timestamp便于后续按时间排序 - 不要直接 push 到数组后整个覆盖
localStorage—— 多标签页同时操作会导致丢失数据；应先读、再修改、再写回 - 示例添加逻辑：
function addBookmark(title, url) {
const bookmarks = JSON.parse(localStorage.getItem('menuBookmarks') || '[]');
if (bookmarks.some(b => b.url === url)) return; // 防重复
const newItem = { id: Date.now(), title, url, timestamp: Date.now() };
localStorage.setItem('menuBookmarks', JSON.stringify([newItem, ...bookmarks]));
}
怎么在页面上渲染可点击的收藏菜单
收藏数据有了，得把它变成用户能看、能删、能跳转的 DOM。重点是绑定事件时别漏掉动态生成的元素，也别让点击跳转触发默认行为干扰收藏逻辑。
- 用
document.getElementById('bookmark-menu')获取容器，每次刷新后用 JS 重建列表（不依赖服务端模板） - 每个收藏项用
<li>包裹，内部放<a href="xxx"></a>用于跳转，再加一个带data-id的删除按钮 - 删除按钮的 click 事件必须调用
event.stopPropagation()，否则会冒泡触发外层<a></a>的跳转 - 跳转前建议加
target="_blank"或检查是否同域，避免当前页被意外关闭
为什么不能用 sessionStorage 替代 localStorage
两者 API 几乎一样，但语义和生命周期完全不同，选错就等于功能失效。
立即学习“前端免费学习笔记（深入）”；
-
sessionStorage在关闭标签页后自动清空 —— 用户刚收藏完切走查资料，回来发现全没了 - 它只在单个标签页生效，多开同个页面的标签页之间不共享数据，无法做到“一处收藏、处处可见”
- 只有极少数场景适用，比如临时导航历史（非收藏）、表单草稿暂存（用户明确知道不会跨会话保留）
- 如果真要用
sessionStorage，记得改所有localStorage调用为sessionStorage，包括读、写、清除
容易被忽略的兼容性和边界问题
看似几行代码的事，上线后常因细节翻车。最常踩的三个坑是：
-
localStorage达到容量上限（通常 5–10MB）时，setItem会抛QuotaExceededError，需用 try/catch 包裹，并提示用户清理 - 用户禁用本地存储（如隐私模式、某些企业浏览器策略），
localStorage为null，直接调用.getItem()会报错，要先判断是否存在 - URL 中含特殊字符（如
#、?）未编码，存进localStorage没问题，但后续用作<a href></a>时可能被截断，建议统一用encodeURIComponent(url)存、decodeURIComponent()取
真正难的不是“怎么存”，而是怎么让收藏行为对用户透明、稳定、不丢数据 —— 尤其当菜单本身是动态加载、SPA 路由切换频繁时，初始化时机和存储同步节奏稍不注意就会错乱。
