在小程序里填到一半的收货信息，临时切去订单页查个单号，再回来时输入框已经空了。不少人的第一反应是表单组件出了毛病，反复检查输入框绑定和事件监听，却始终找不到症结。这类现象大多不属于组件故障，而是页面状态在往返过程中没有被正确保持。核对顺序如果从组件入手，往往越查越乱，更稳妥的做法是按页面栈、状态存放位置、回填时机、提交取值四个层次依次排查。
先要分清问题属于哪一种类型。第一种是页面被销毁后重建，返回时是一个全新的页面实例，内存里的表单内容自然不存在。第二种是页面没有销毁，但数据没有回填到输入框，用户看到的是空白界面，实际数据可能还在。第三种是数据回填正常，但提交时读到的却是旧值或空值。三种情况的排查方向完全不同，混在一起判断容易把简单问题复杂化。
第一步核对页面栈行为。小程序的页面跳转方式决定了当前页面是否会被卸载，某些返回操作会触发页面卸载，卸载后页面内存中的临时状态随之消失。实际排查时，可以在页面的生命周期钩子中打点观察，记录页面加载、显示、隐藏、卸载的触发顺序，再对照用户的操作路径，确认返回时页面究竟经历了什么。如果日志显示返回时页面被重新加载，那么问题根源就在页面栈层面，而不是表单本身。
第二步核对状态存放位置。表单数据通常有三种存放方式：组件内部状态、页面级状态、全局状态。组件内部状态随组件销毁而丢失，页面级状态在页面卸载后消失，全局状态则可以在多个页面之间保留。跨页面往返时，需要明确哪些数据必须放在全局或本地缓存中，哪些可以留在页面内。把应该长期保留的数据放在组件内部，是表单丢失的常见原因。
第三步核对回填时机。数据存下来了，不代表能正确显示。回填动作如果发生在表单组件初始化之前，数据可能被随后的初始化覆盖；如果发生在渲染完成之后，又可能出现界面先空后填的闪烁。合理的顺序是先恢复数据，再让表单以这份数据完成首次渲染。排查时可以观察回填代码与组件创建、页面显示这几个节点的先后关系，确认数据写入时表单是否已经准备好接收。
第四步核对提交链路。有些表单看起来是空的，提交后却带上了旧值，这通常是因为提交时读取的数据源与界面显示的数据源不是同一个。比如界面绑定的是页面级变量，提交时读的却是全局缓存中的历史数据。检查时要把提交前的取值来源统一到一处，确保界面显示什么、提交就取什么，避免两套数据各自为政。
把以上四步整理成一份核对清单会更实用：页面栈是否发生卸载重建，状态存放在组件、页面还是全局，回填是否早于表单初始化，提交取值是否与界面同源。四项逐一确认，多数表单丢失问题可以在不改动整体架构的前提下定位。在小程序开发中，把数据从进入到离开的生命周期画成一张简单流程图，能明显减少这类返工。在需求梳理阶段提前约定哪些数据需要跨页面保留、由谁负责恢复，比上线后再逐页排查更省力。状态保持不是某个组件的能力，而是页面之间协作的结果，顺序对了，问题就清楚了一半。
