PHP站点多输入字段页面如何防止会话超时导致数据丢失

我在多个带大篇幅表单的PHP项目（企业内部ERP、政务申报系统、电商售后审核页）里处理过完全相同的问题，前后试过不同方案，最终的稳定版本已经跑了3年多，没有再收到用户填写数据意外丢失的反馈。

你提到的三个思路的实测问题 #

先逐个说下这三个思路在真实用户场景下的硬伤：

• 15分钟倒计时提醒保存：体验很差。首先很多用户填表单是边找材料边填，看到提醒的时候如果正翻附件、核对数据，点完“稍后提醒”转头就忘；还有用户看到弹窗直接关，根本不读提示内容，最后超时还是丢数据。另外“首次输入启动计时”的逻辑有漏洞：如果用户填了10分钟出去接20分钟电话，回来接着填的时候会话早就过期了，倒计时还剩5分钟，完全起不到作用。我们最早用过这个方案，上线后相关投诉只降了30%，根本没解决核心问题。
• 固定间隔AJAX保活会话：逻辑最轻，但破坏了原有的会话超时安全规则。如果用户开着表单页直接下班、忘了关页面，保活请求会一直发，会话永远不过期，公用电脑场景下有账号被他人冒用的风险；另外如果用户网络临时波动，保活请求失败，等用户填完点保存还是会跳登录页，数据照样丢。
• 定时AJAX后台自动保存：你们团队不认可大概率是顾虑脏数据问题——直接往正式业务表写草稿会产生大量未提交的无效数据，还要额外加草稿状态、定期清理逻辑、草稿和正式数据的冲突判断，改造成本不低。

最优组合方案（无需大改后台、无脏数据、兼容现有会话规则） #

这套方案不需要调整现有PHP后端的会话逻辑，也不用新建草稿表，前端加100多行代码就能搞定：

• 本地草稿做核心兜底
  监听所有输入框、文本域、选择器的input和change事件，加3秒防抖，每次用户输入停顿3秒后，就把全量表单数据序列化后存在localStorage里，存储key用「当前页面路径+用户登录标识」区分，避免同站点多个表单草稿互相覆盖。
  页面加载时优先检查本地有没有对应未提交的草稿，如果有就弹明确提示：「检测到您上次有未提交的填写内容，是否恢复？」，提供「恢复内容」「清空草稿」两个选项。用户主动点击保存、提交成功后，立刻删除对应的本地草稿。
  这个逻辑完全在前端实现，200个字段的表单序列化后也就几KB，存在本地毫无压力，哪怕会话过期、浏览器崩溃、电脑意外断电，只要用户用同一个浏览器打开页面，数据都能找回。
• 带触发条件的会话保活，不破坏原有安全规则
  不要固定间隔发保活请求，先加两个前置判断：① 用document.visibilityState判断页面是否处于激活状态，切到后台、最小化的时候不发请求；② 最近2分钟内有用户输入、点击、鼠标移动这类活跃操作。两个条件同时满足时，才每15分钟发一次轻量AJAX请求，请求的地址只需要是一个开头加了session_start()的空PHP文件即可，不需要多余逻辑，就能实现会话续期。
  额外加个异常判断：如果保活请求返回登录页标识、或者302跳转到登录地址，立刻在页面顶部弹强提示条：「当前登录状态已失效，请先在新标签页完成登录，再返回当前页面提交，已填内容已自动暂存不会丢失」，不要等用户填完点保存才告知会话过期。
• 低打扰的超时提醒
  不要从首次输入就启动倒计时，每次页面加载、保活成功、提交成功的时候，把当前时间戳存在前端，按照20分钟超时计算剩余时间，剩余3分钟时如果页面仍处于活跃状态，在页面顶部飘个非阻断的黄色提示条（不要弹模态框打断用户输入），写明「登录状态还有3分钟过期，已填内容已自动暂存不会丢失」，附带一个「续期登录」按钮，用户点一下就发保活请求重置计时。

注意不要用sessionStorage存草稿，用户关闭标签页数据就会被清空，起不到兜底作用；如果表单包含身份证、银行卡这类敏感字段，可以在存储到本地前做一次轻量前端加密，避免被本地其他脚本读取。

这套方案上线后，我们负责的几个长表单页面的数据丢失投诉直接降到0，既没有后台自动保存产生脏数据的问题，也没有无限制保活带来的安全风险，改造成本远低于纯后台实现的方案。

内容的提问来源于stack exchange，提问作者Daniel Jørgensen