Page Lifecycle API无法监听系统强制回收瞬间，仅能通过pagehide、visibilitychange等事件做预防性保存与启动时智能恢复。
Page Lifecycle API 本身不提供“系统回收瞬间”的精确监听能力，尤其在 Android 或 iOS 的后台进程被系统强制终止时（如内存不足、用户切换到其他应用后系统杀掉网页进程），页面会直接静默销毁，没有任何 JS 执行机会。所谓“监听回收瞬间并还原未保存输入”，实际是通过生命周期事件做尽可能早的预防性保存 + 启动时智能恢复，而非真正捕获“被杀那一刻”。
关键可用生命周期事件与适用场景
Page Lifecycle API（主要基于 document.visibilityState 和 pagehide/visibilitychange）能可靠捕获的是用户主动离开或页面即将不可见的时机，而非系统强制回收：
-
pagehide：页面即将隐藏或卸载（包括用户关闭标签页、导航离开、浏览器休眠）。event.persisted === false时大概率是彻底卸载，是最后可靠的保存时机。 -
visibilitychange：页面可见性变化（如切到其他标签页、锁屏）。适合轻量级自动保存（如防抖存草稿），但不能保证后续页面不被销毁。 -
beforeunload（非 Lifecycle API，但常配合使用）：用户尝试关闭/刷新页面前触发，可弹出确认框，但无法异步保存数据（如发请求），仅适合同步写入localStorage。 -
freeze：页面被冻结（Chrome 中后台标签页可能触发），JS 暂停执行，无代码执行机会，不可用于保存。
未保存输入的可靠保存策略
核心原则：不要等到“最后一刻”，而要持续、防抖、分层保存：
-
实时监听 + 防抖写入 localStorage：对
<input>、<textarea>绑定input事件，用setTimeout防抖（如 500ms），将内容序列化后存入localStorage，键名建议包含 URL 或表单 ID（如`draft_${location.pathname}`）。 -
在
pagehide中强制落盘：即使有防抖，也要在pagehide里立即执行一次最终保存，覆盖可能未触发的防抖写入。 -
避免依赖 sessionStorage：它在页面关闭后即失效，不如
localStorage可跨会话保留。 -
记录时间戳与校验：保存时附带
savedAt: Date.now()，恢复时可判断草稿是否过期（如超过 7 天）。
页面加载时的智能还原逻辑
还原不是简单“填回去”，需兼顾用户体验与数据安全：
-
只在页面首次加载且无用户输入时还原：检查
textarea.value.length === 0再恢复，避免覆盖用户新输入。 - 提供明确的还原提示与操作按钮：例如在表单顶部显示“检测到未完成的草稿，是否恢复？[恢复][忽略]”，而不是静默填充。
- 还原后清除 localStorage 草稿：防止重复恢复；若用户点击“忽略”，也应主动清除，避免下次再弹。
-
处理多字段场景：将整个表单状态 JSON 序列化保存（如
{ title: "...", content: "...", timestamp: ... }），还原时遍历 DOM 匹配name或data-draft-key属性。
无法覆盖的边界情况与应对建议
必须向团队和用户坦诚技术限制：
-
Android PWA 被系统杀死、iOS Safari 后台标签页冻结后强退：无任何 JS 执行机会，
pagehide不会触发。唯一缓解方式是更激进的防抖（如 200ms）+ 关键操作后立即保存（如用户停顿 1 秒就存）。 -
隐私模式 / 无痕窗口：
localStorage在关闭窗口后清空，草稿必然丢失。可在进入页面时检测localStorage是否可用，不可用时降级为内存缓存 + 强烈提示“请勿使用无痕模式编辑重要文档”。 -
跨设备同步需求：需结合后端 API 实现云端草稿（如定时 POST 到 /api/drafts），前端仍保留本地 fallback。此时
pagehide是触发最终同步的关键钩子。
