表单提交前如何检测是否已超时
浏览器本身不自动追踪表单生命周期，超时必须靠开发者主动维护状态。常见做法是提交前比对当前时间与表单初始化/加载时间戳的差值。
容易踩的坑：setTimeout 不可靠——页面切到后台时定时器可能被节流甚至暂停；用 Date.now() 做实时计算更稳妥。
- 在表单渲染完成时记录
formCreatedAt = Date.now() - 提交前检查
if (Date.now() - formCreatedAt > 300000)（例如 5 分钟） - 若超时，阻止
submit事件，并提示用户重新加载表单 - 注意：服务端也必须校验时间戳，前端校验可被绕过
后端怎么验证表单时效性
前端时间不可信，服务端必须独立判断请求是否“新鲜”。关键不是看服务器当前时间，而是看请求携带的时间凭证是否在允许窗口内。
典型方案是表单里藏一个隐藏字段 form_timestamp，值为服务端生成的 Unix 时间戳（毫秒），并配合签名防篡改。
立即学习“前端免费学习笔记（深入）”；
- 渲染表单时，后端写入
<input type="hidden" name="form_timestamp" value="1717023456789"> - 同时生成签名：比如
HMAC-SHA256(form_timestamp + secret_key)，存入form_signature - 收到 POST 后，先校验
form_signature是否匹配，再算abs(now - form_timestamp) - PHP 示例中别直接用
time()比较，要转成毫秒或统一用秒，避免单位错位
为什么不能只依赖 session 过期
Session 超时和表单超时不是一回事。用户 session 还活着，但某张表单可能已打开 20 分钟未提交——这时提交仍会成功，却可能造成数据不一致或并发冲突。
常见错误现象：用户填完表单、切去查邮件、回来点提交，结果订单重复创建或库存扣减失败。
- Session 生命周期通常以“最后活动时间”为准，而表单有效期应从“生成时刻”起算
- 同一个 session 下可存在多个不同有效期的表单（如编辑页 vs 新建页），需各自管理
- 若用
session.gc_maxlifetime控制，无法区分具体表单，且 PHP 默认 1440 秒（24 分钟）未必匹配业务要求
带 token 的表单怎样防止重放攻击
单纯加时间戳还不够，攻击者截获请求后稍作修改重发，照样能通过时效校验。必须绑定一次性 token 或强绑定上下文。
推荐组合策略：时间戳 + 单次有效 token + 用户行为指纹（如 IP 前缀、User-Agent 简化哈希）。
- 生成表单时，后端写入
form_token = bin2hex(random_bytes(16))，并存入缓存（如 Redis），设置相同 TTL - 提交时校验
form_token是否存在且未被使用过；验证通过后立即DEL对应 key - Redis key 建议带前缀，如
form_token:u12345:1717023456789，便于按用户清理 - 注意：不要把 token 放在 URL 里，避免泄露；也不要用
localStorage存，易被 XSS 读取
表单超时最麻烦的不是逻辑写不出来，而是前后端时间不同步、token 清理遗漏、以及忘记在重定向后的新表单里刷新时间戳——这几个点漏掉一个，就等于没做。
