打开微信，点进任何一个电商类小程序，下单前总得先过地址管理这一关。你填过多少次收货地址？又因为地址列表里躺着五六个旧地址，手滑选错而懊恼过？对开发者来说，地址模块看起来就是个表单加列表，真做起来却藏着不少坑。我从零开始搭过一个完整的收货地址模块，今天就把那些踩过的坑、试对的路，一条条掰开揉碎了讲给你听。

先别急着写代码，得想清楚这个模块到底要管哪些事。地址管理不是让你存一串字符串就完事，它要处理的是结构化数据：收货人姓名、手机号、省市区、详细地址、邮编，还有默认地址标记。我见过不少新手直接把整个地址拼成一个字段存进数据库，结果后续要按城市做统计，或者给用户推荐同城商品时，只能对着字符串干瞪眼。所以第一步，把字段拆细，省市区单独存，详细地址单独存，宁可多几个字段，也别偷懒。

表单页面是用户直接接触的部分，体验好坏全看这里。省市区选择器，微信小程序官方给了picker组件，mode设为region，能直接调起微信自带的省市区选择，省去自己维护行政区划数据的麻烦。但有个细节容易忽略：用户可能从历史地址里编辑，这时候省市区得能回显。picker的value属性要传一个数组，比如['广东省','深圳市','南山区']，如果数据库里存的是行政区域代码，还得先做一层映射转换。我当初在这里卡了半天，后来干脆在本地存一份省市区JSON，用代码查名称，才把回显问题解决。

手机号校验这块，别只盯着正则表达式。用户填错手机号，前端正则能拦住大部分，但还有种情况：用户填了座机号，或者写了分机号。我见过有人直接在正则里写死1开头的11位数字，结果用户想填公司座机就怎么也提交不了。折中方案是做个宽松校验：要么是11位手机号，要么是带区号的座机格式，至少让用户能把地址存下来，别因为一个电话字段卡死整个流程。

地址列表页，重点不在展示，在操作效率。用户要的是快速找到常用地址，一键选中。所以列表项上，默认地址要明显标记，比如右上角一个绿色小标签。编辑和删除按钮别藏太深，左滑删除虽然省空间，但发现成本高，很多用户根本不知道能左滑。我做的是在每条地址下面直接放两个小按钮：编辑、删除，简单粗暴，用户不用猜。另外，列表要按更新时间倒序排，刚编辑过的地址排前面，这是用户最可能想用的。

默认地址的逻辑，得单独拎出来想清楚。用户设置了一个默认地址，后面新增地址时，要不要自动把默认标记取消？我的做法是：新增地址时提供一个“设为默认地址”的开关，如果用户勾选了，就把旧默认地址的标记清掉，新地址设为默认。如果没勾选，新地址就乖乖当普通地址。这里有个隐蔽的坑：用户可能删除了默认地址，那剩下地址里，得自动挑一个设为新的默认，不然下次下单时系统找不到默认地址，容易报错。我在删除接口里加了这段逻辑，才把这个问题兜住。

存储方案上，本地缓存还是后端接口？如果你做的是纯前端demo，用wx.setStorageSync存本地就行，简单省事。但真实项目里，地址数据肯定要同步到服务端，不然用户换个设备登录，地址全丢了。我建议做两层：界面操作走后端API，同时把最近一次成功拉取的地址列表缓存在本地。这样用户在网络差的时候，至少能看一眼旧地址，不至于白屏。等网络恢复，再静默更新。

编辑和新增共用一个页面，这个设计能省不少代码。页面里放一个隐藏的addressId字段，有值就是编辑模式，没值就是新增模式。提交时根据这个字段决定调创建接口还是更新接口。表单验证逻辑完全复用，唯一要注意的是：编辑模式下，初始数据得回填到表单控件里，而且回填时机要等页面onLoad拿到参数后再执行，别在data里写死初始值。

还有一个容易被忽略的点：地址模块和订单模块的联动。用户在下单页选地址，选完应该能直接展示出来，并且支持跳转到地址管理页去新增或编辑。这里用事件通道或者全局状态管理都可以。我用的是小程序自带的事件总线，选完地址后通过eventChannel把新地址传回订单页，刷新展示。这个交互做顺了，整个下单流程会流畅很多。

写到这里，回头看看，地址模块虽然小，五脏俱全。从字段设计到表单交互，从列表操作到默认逻辑，再到数据同步和跨页面联动，每一个环节都有值得琢磨的细节。我踩过的最大的坑，就是一开始把地址当成一个简单的字符串字段处理，后来各种需求找上门，才被迫重构。如果你正准备开发这个小程序里的“小模块”，不妨从设计数据结构开始，多花点时间想清楚边界情况，后面写代码会顺畅得多。毕竟，用户不会因为你地址模块做得好就夸你，但会因为地址选错、填不了而直接卸载小程序。