应通过用户编辑行为而非页面关闭事件识别表单放弃：首次聚焦时启动计时，以input/blur/visibilitychange综合判断是否真实中断，结合hasedited标记与静默阈值（如60秒），用sendbeacon轻量上报，后端需支持text/plain解析并去重。
怎么用 JavaScript 捕获用户中途关闭或跳失表单
关键不是监听“关闭页面”，而是识别用户在关键字段前就停止操作。浏览器不提供直接的“表单放弃”事件，得靠行为推断。
常见错误现象：beforeunload 被滥用，导致所有离开都算放弃；没区分主动提交失败和真放弃；忽略移动端无焦点切换的场景。
- 只在用户首次聚焦第一个输入框时启动计时器（
startTime = Date.now()），避免页面加载即触发误判 - 监听
blur或input事件判断是否进入过编辑，而非仅靠focus - 对多步表单，每步保存
step_1_entered、step_2_started等布尔标记，比总时长更可靠 - 注意移动端
blur不稳定，可配合visibilitychange+ 页面可见性判断是否真的离开了
如何区分「放弃」和「暂时离开」
用户切到微信回消息再回来，不该记为放弃。核心是看有没有「意图中断」信号，而不是单纯看停留时间。
使用场景：注册页、支付页、问卷首屏等高流失环节。
立即学习“前端免费学习笔记（深入）”；
- 设置合理静默阈值（比如 60 秒无任何
input、click、keydown），但别硬设 5 分钟——多数放弃发生在前 90 秒 - 如果用户曾修改过至少一个字段（
hasEdited = true），再离开才计入放弃；纯浏览不算 - 避开自动填充干扰：Chrome 自动填充会触发
input，但用户没动手。可用event.inputType === 'insertText'或检查e.isTrusted过滤
后端怎么接收并存下放弃行为数据
前端上报必须轻量、异步、容错。别等 beforeunload 里发请求——90% 会失败。
性能影响：同步 XHR 在卸载时阻塞关闭，兼容性差；sendBeacon 是唯一靠谱方案。
- 用
navigator.sendBeacon('/api/abandon', JSON.stringify(payload))，它不依赖页面存活 - payload 至少包含：
form_id、last_focused_field、edit_duration_ms、step - 服务端接收接口必须支持
text/plain（sendBeacon不发Content-Type: application/json），用req.body.toString()解析 - 别漏处理重复上报：同一
form_id+session_id10 分钟内只记首次
为什么 Google Analytics 4 默认不抓表单放弃点
GA4 的 form_start 和 form_submit 事件依赖开发者手动打点，它本身不监听 DOM 行为。原生不识别“放弃”。
容易踩的坑：直接套用 GA4 表单模板，结果只看到提交数，放弃率永远是 0。
- 必须自己用
gtag('event', 'form_abandon', {...})上报，且确保在sendBeacon后再调用（避免竞态） - GA4 中
form_abandon是自定义事件，需提前在后台配置转化路径，否则无法参与归因分析 - 别把
page_location当作表单标识——同一 URL 可能有多个表单，要用form_id或data-form-id属性提取
放弃点不是某个时刻，而是一组行为组合。最常被忽略的是：没验证用户是否真“动过手”，就把页面停留短等同于放弃。静默、自动填充、iframe 表单、PWA 缓存都会扭曲数据。先稳住信号源，再谈分析。
