localStorage保存草稿需关注时机、防覆盖与恢复逻辑：存前校验内容非空并动态生成key；加载时仅在编辑框为空时恢复最新草稿；输入时防抖节流保存并比对内容变化；发布或清空后同步删除对应key，禁用clear()。
按钮点击触发 localStorage 保存草稿
直接用 localStorage.setItem() 把内容存进去就行，但关键不是“能不能存”，而是“什么时候取、怎么避免覆盖、用户关掉页面再打开还能不能对得上”。localStorage 是同步 API，不卡 UI，但没错误提示——写错 key 或传了 undefined 都静默失败。
- 保存前务必检查输入框值是否为空或纯空白，否则会把空字符串或换行符当有效草稿：
if (content.trim()) { localStorage.setItem('draft', content) } - 别用固定 key（比如硬写
'draft'），多人共用同一域名时会互相覆盖；建议加时间戳或哈希标识：localStorage.setItem('draft_v2_' + Date.now(), content) - 按钮的
onclick里不要只调保存函数，得同步更新按钮状态（比如加 loading 提示），否则用户狂点多次，可能触发重复写入（虽然不影响结果，但浪费）
页面加载时自动恢复草稿内容
恢复不是简单读出来就完事。用户可能刚打开页面，编辑框还是空的，但 localStorage 里有旧草稿——这时候要不要自动填充？填了又怕覆盖用户本意清空的内容。稳妥做法是：只在编辑框初始为空时才恢复。
- 用
document.getElementById('editor').value || localStorage.getItem('draft_v2_...')这种短路逻辑，避免空值覆盖已有内容 - 不要在
DOMContentLoaded里立刻读取，等 DOM 渲染完成、编辑框可访问后再执行；否则可能取到 null 或未挂载的元素 - 如果用了多个草稿版本（比如按日期分），恢复时得找最新一条：
Object.keys(localStorage).filter(k => k.startsWith('draft_v2_')).sort().pop()，再取值
监听输入实时保存（防崩溃丢失）
光靠按钮不够。用户打字中途浏览器崩溃、断电、误关标签页，按钮根本没机会点。必须用 input 或 keydown 事件做节流保存，但别每敲一个字都写一次 localStorage——性能差，还可能触发浏览器写入限频（尤其 Safari 对频繁写入很敏感）。
- 用
setTimeout做防抖：用户停顿 800ms 后再保存，既及时又不频繁 - 避免在
input事件里直接调localStorage.setItem()，先判断内容是否真变了（prevContent !== currentContent），否则无意义写入 - 注意移动端软键盘弹起/收起也会触发
input，但内容未必变；建议加个isComposing判断（中文输入法正在组词时为 true），跳过中间态
清除草稿的边界情况处理
用户点“发布”或“清空”后，必须同步清理 localStorage，否则下次打开还挂着旧内容。但这事容易漏——比如发布成功后跳转了，没来得及删；或者清空按钮只清了 DOM，没碰 storage。
立即学习“前端免费学习笔记（深入）”；
- 发布成功回调里，用
localStorage.removeItem('draft_v2_xxx')明确删除对应 key - 清空按钮要同时清 DOM 和 storage：
document.getElementById('editor').value = '';+localStorage.removeItem(...) - 别用
localStorage.clear()，它会干掉所有其他功能依赖的 storage 数据（比如用户偏好、token），影响太大
真正麻烦的是多标签页场景：用户开了两个编辑页，A 页存了草稿，B 页点了发布并删了 storage，A 页再切回来还在用旧数据——这种需要监听 storage 事件做跨页同步，但兼容性和可靠性都不高，多数产品选择忽略，只保证单页内一致。
