小程序表单填到一半，点返回想确认个信息，再回来发现前面填的全空了。开发群里这类反馈很常见，但要是直接归到“缓存没做好”上，多半修不准。表单内容丢失，通常是页面生命周期、状态存放位置和导航方式三件事叠在一起造成的，得按顺序拆开看。
先分清用户说的“返回”是哪种动作
第一种是点左上角返回上一页，属于页面栈回退；第二种是在页面内切换标签或步骤，页面本身没离开；第三种是切到后台、锁屏或直接退出小程序。这三种动作对页面状态的影响完全不一样：页面栈回退可能触发页面销毁，页面内切换一般只是局部刷新，切后台则取决于系统对页面的回收策略。先把动作归好类，才能判断丢失发生在哪一层。
再核对页面栈与导航方式
普通返回会把当前页弹出页面栈，页面实例跟着销毁，页面内部的临时变量自然留不住。如果代码里用了重定向或重新加载的方式跳转，看着像“返回”，实际是新建了一个页面实例，数据同样带不回来。排查时可以观察页面有没有重新执行初始化逻辑、默认值有没有被重新写入，这能帮助确认页面是不是被销毁重建了。
然后看表单数据放在哪里
放在页面内部变量里，页面销毁即丢失，适合一次填写、不涉及返回的场景。放在全局状态里，页面重建后可以读回，但要处理何时写入、何时清理，避免不同用户或不同表单之间串数据。放在本地缓存里，能扛住退出和切后台，但要注意缓存键的区分、过期策略和敏感信息的存放边界。三种做法没有优劣，关键是和表单的使用路径匹配。
可执行的检查清单
返回前是否主动触发了一次保存；页面恢复时是否用默认值覆盖了已存内容；多步骤表单是否每一步都分步留存，而不是只在最后统一提交；异常退出后是否需要提供草稿恢复入口；同一表单多次进入时，旧数据是否被正确清空。逐项对照，多数丢失问题能定位到具体环节。
测试与验收要覆盖完整路径
填写后返回再进入、填写中切换标签、填写中切后台再回来、填写中直接退出再打开、多步骤表单中途返回上一步。每种路径都记录数据是否保留、恢复的是哪一版内容。涉及具体框架的生命周期钩子和缓存接口行为时，应以官方文档和实际测试结果为准，不同版本之间可能存在差异。
表单内容丢失看着是小问题，背后是状态变化没被说明白、恢复逻辑没被做清楚。把动作分类、存放位置和恢复时机在设计阶段就写进需求，测试阶段按路径逐条验证，返工就会少很多。it数运在需求梳理和测试环节习惯先把这类状态变化列成清单，再进入实现，让交付过程更可控。
