用户在小程序里下单，第一次填完地址，第二次进来还要从头再填一遍。表面看只是多点几下，实际影响的是下单转化：地址填写是支付前最繁琐的一段，重复劳动越多，中途放弃的人就越多。很多开发团队把地址记忆当成一个开关，要么存要么不存，结果不是用户嫌麻烦，就是用户嫌越界。真正要解决的是：哪些地址该记住，记在哪里，什么时候带出来，什么时候必须重新确认。
先分清三类地址信息
第一类是常用地址，比如家庭住址、公司地址，用户会反复使用。这类适合长期保存，并允许设置默认值。第二类是临时地址，比如出差酒店、临时收货点，用过一次基本不再用。这类适合短期保存，或者只在当前会话内有效，过期自动清理。第三类是历史地址，用户曾经填过但已经不再常用。这类适合保留在列表里供选择，但不应该自动成为默认值。三类混在一起，用户打开地址列表就是一堆杂乱记录，反而更难选。
本地缓存与账号绑定各有取舍
本地缓存实现简单，用户不登录也能用，但换设备、清缓存、卸载重装后数据就没了，同一台手机换账号登录还可能串数据。账号绑定把地址存在服务端，换设备登录后依然能带出，但需要用户先登录，也意味着地址信息离开了用户设备。比较稳妥的做法是两者结合：未登录时用本地缓存兜住当前流程，登录后把本地地址合并到账号下，并让用户确认是否保留。关键是合并时不要静默覆盖，避免把别人的地址带进来。
授权与隐私边界要划清楚
可以默认带出的，是用户自己保存过、且明确设为常用的地址。必须每次确认的，是手机号、详细门牌、涉及他人代收的信息。不要因为用户上次填过，就默认这次还用同一个号码，更不要在用户没授权的情况下读取通讯录或聊天记录里的地址。地址属于个人信息，保存前应有明确告知，保存后要提供查看、修改和删除入口。用户选择删除，就要真的从本地和服务端都清掉，而不是只从界面上隐藏。
一份可执行的检查清单
字段设计上，区分必填与选填，省市区与详细地址分开存储，避免整段文本难以解析。默认值上，只把用户主动设为常用的地址作为默认，临时地址不参与默认。编辑入口上，地址列表每一项都能直接修改，不要只能删除再重填。删除入口上，单条删除和全部清空都要有，并给出明确反馈。异常处理上，换设备登录后如果地址为空，应引导重新填写而不是报错。过期策略上，临时地址设置合理有效期，到期自动清理并告知用户。
小结
地址记忆逻辑的目标不是替用户做决定，而是让用户少做重复动作，同时始终掌握控制权。记住什么、记多久、什么时候带出来，都应该有清晰规则，并且让用户看得见、改得了、删得掉。把这件事做扎实，下单流程会顺很多，用户对小程序也会更放心。
