WebView 返回小程序：如何交接数据与下一步动作

关联项目：定制家具设计与报价系统。本地流程已有 WebView 同步数据、保存待处理动作、在页面恢复时消费的结构。本文进一步分析动作归属与幂等边界，新增方案不等同于现有实现。

返回页面是一件事，完成交接是另一件事

用户在内嵌网页中完成操作，点击下一步返回小程序。小程序页面恢复显示，并不自动说明数据已经写好、动作已经收到，或者下一步条件已经满足。

若把所有逻辑写成“页面一显示就跳下一步”，普通返回、重复显示和消息延迟都可能推进错误流程。

先确认消息什么时候交付

小程序 WebView 的消息行为与浏览器 iframe 不应混为一谈。uni-app 文档说明，网页向应用发送的消息会在特定时机触发接收；具体行为需对照目标平台，见 web-view 文档。因此不能把发送动作直接理解成即时完成的跨页调用。

页面恢复、消息接收与业务同步应作为不同事件观察。在目标环境里记录实际顺序，才能决定哪里是可靠的处理入口。

给交接一个明确身份

在已有待处理动作的基础上，可以进一步设计一次交接记录。它至少需要回答：属于哪个设计草稿、哪一次网页打开过程、用户希望做什么，以及数据对应哪个版本。

动作身份用于拒绝旧网页留下的消息，也可以区分同一次交接的重复通知。身份来自应用契约，不应通过“等 300ms 应该够了”来模拟。

这只是待实施的协议设计方向；如果现有消息没有版本或动作 ID，不能声称消费者已经可以可靠去重。

同步、验证、消费分别负责什么

1. 校验消息结构和归属，只更新允许同步的字段。
2. 应用这一版本的数据，判断用户要求的下一步是否具备条件。
3. 处理有效动作，并记录或清除对应待处理状态。
4. 页面再次恢复时，已处理动作不应重复生效。

如果先清除动作再导航，导航失败时要保留可恢复信息；如果先导航后清除，就要防止重复执行。具体选择取决于动作能否重试，不能仅调整两行代码顺序就宣称严格一次执行。

系统返回不等于点击下一步

用户主动返回、网页点击上一步、网页点击下一步，含义不同。没有动作记录时，应按正常返回路径处理；缺少数据时，应停在可修正的位置，而不是继续触发后续接口。

页面重启可能丢失内存中的待处理状态。是否需要持久化草稿和交接信息，应根据恢复目标决定，同时设置过期与归属检查。

在真实宿主中验证交接

覆盖下一步、普通返回、消息延迟、重复消息、旧网页消息、导航失败和小程序重新进入。分别检查数据、当前步骤与动作消费状态，而不只观察有没有跳页。

H5 页面测试可以覆盖处理函数，无法独自证明小程序 WebView 的消息时序。最后一段验证必须回到目标宿主。