小程序里删掉一条收货地址，表面看只是列表少了一行，但到了下单结算那一步，问题才真正暴露：系统提示没有默认地址，或者订单直接卡在提交环节。这类故障的根源通常不在“删除”这个动作，而在于删除之后没有一套清晰的补位规则。地址簿并非静态清单，它同时参与展示、选择、运费计算和配送范围匹配，默认项一旦消失，后续链路就可能接连失灵。
地址簿里其实有三种不同角色
不少开发团队把地址簿当成一组普通记录来处理，但实际使用中，地址至少承担三种职能。默认地址是结算时优先带入的那一条，一般只有一个。常用地址是用户反复选用、却未必设为默认的地址，可能有多条。临时地址则多为一次性场景，比如代收、出差酒店，用完就很少再打开。三类地址的生命周期并不相同，删除默认地址后，能否从常用地址补位、能否从临时地址补位，判断标准也不一样。如果字段设计没有区分来源和状态，补位就只能靠猜。
补位顺序应该怎么定
补位不是随便挑一条顶上，而是让用户几乎无感地继续下单。一个可落地的顺序是：先看最近使用时间，把最近三十天内下过单的地址排在前面；再看是否与当前定位或常用收货城市一致，同城地址优先；最后看用户是否手动置顶过某条地址。如果以上都没有，才考虑按创建时间倒序取最新一条。需要提醒的是，补位只应发生在结算入口，不应直接改写用户的默认标记。也就是说，系统可以临时选一条地址用于本次结算，但不要悄悄替用户把默认地址改成另一条，否则用户下次打开地址簿会发现自己的设置被动了。
补位逻辑落地时要同步检查的边界
补位规则确定后，还要检查几个容易漏掉的边界。第一是无可用地址的情况，此时结算页应给出明确的添加入口，而不是反复提示默认地址缺失。第二是多端同步，用户在手机端删除了默认地址，平板或网页端不应继续显示旧状态，接口返回时要带版本号或时间戳。第三是缓存刷新，地址簿列表和结算页往往读的是不同缓存，删除后要确保两处同时失效。第四是配送范围校验，补位出来的地址如果不在配送范围内，应提前提示而不是等到支付后才报错。
上线前可以逐项核对的地址簿状态清单
为了减少返工，建议在上线前对照一份清单逐项确认：删除默认地址后，结算页是否还能正常进入；补位地址是否参与运费计算；地址簿列表的默认标记是否与结算页一致；无地址时是否有添加入口；多端删除后另一端是否同步；缓存是否在删除后立即失效；补位地址超出配送范围时是否有前置提示；用户手动置顶的地址是否优先于最近使用。把这些状态走一遍，比事后反复修 bug 更省力。it数运在参与小程序开发时，通常会把地址簿的状态流转单独列成一张检查表，因为这类问题一旦漏掉，用户感知到的就是下单失败，而不是某个字段没处理好。把补位逻辑想清楚，地址簿才算真正可用。
