从零到一：微信小程序地址管理避坑与自定义选择器实战

我最近在做一个微信小程序的项目，涉及地址管理这块功能。说实话，刚开始觉得这玩意儿挺简单的——不就是让用户填个收货地址嘛。结果真正动手时才发现，坑比想象的多。就说那个省市区三级联动的选择器，看似简单，实际上一堆细节要处理。比如用户点完省份，市和区的列表得跟着刷新，选好后还得校验一下是否真的选了，不然用户提交时发现地址不完整，体验就差了。我一开始直接用了微信官方提供的 picker 组件，但发现样式太丑，和小程序的整体风格不搭。后来干脆自己写了一个自定义的地址选择器，虽然花了不少时间，但至少能控制 UI 的每一个像素。

地址管理最头疼的问题之一是数据来源。微信官方没有提供现成的省市区数据，只能自己找。网上倒是有不少开源的地址库，但质量参差不齐：有的太旧，有的格式不对，还有的带了一堆乱七八糟的字段。我试了三个不同的库，最终选了一个 GitHub 上 star 较多的，但即便如此，仍发现有些地级市的数据不完整，比如某个城市下面的区县漏了好几个。若这些问题上线后，用户反馈找不到自己的地址，那就尴尬了。于是我写了个脚本，把数据跑了一遍，手动补全了缺失的部分。虽然这事儿看起来琐碎，却马虎不得。

接下来说说地址的存储问题。微信小程序运行在客户端，用户填的地址信息最终要存到服务器。最简单的办法是直接存成 JSON 字符串，反正前端传过来的已经是对象了。但如果后续要按省份或城市做数据分析，比如统计用户分布，查询就会很麻烦。于是我决定把省、市、区拆成三个独立的字段，再加一个详细的街道地址字段。这样既能保证查询效率，又不丢失原始信息。不过这样做也有代价：前端表单提交时，需要多做一层数据处理，把选中的省市区的 code 和 name 都传过去。代码稍微复杂了一点，但为了后续的可维护性，这一步不能省。

地址管理还有一个容易被忽视的点，就是用户输入的合法性。用户填地址时可能手滑写错，甚至故意乱写。比如有人会把详细地址写成“随便写写”，如果不做校验直接入库，后面物流派送就会出问题。我加了几层校验逻辑：必填项、省市区不能为空；格式检查，例如手机号必须是 11 位且不能有字母；长度限制，详细地址不能超过 100 个字符。这些校验前后端都要做，前端为了及时提醒用户，后端为了保证数据安全，防止恶意提交。光这块校验，我就改了三版，因为总有一些边界情况没考虑到。

再聊聊地址的默认项。很多电商类应用都有“默认地址”这个概念，用户下单时自动选默认地址，省得每次都手动选择。实现起来并不复杂，只需要在地址表里加一个 is_default 字段。但问题是，如果用户修改了默认地址的某个字段，比如更新了手机号，其他依赖该地址的订单怎么办？我最初没想清楚，后来查资料发现比较好的做法是：地址本身作为独立实体，订单里存的是地址的快照。也就是说用户下单那一刻，地址的所有信息都会复制到订单里，后续地址的修改不影响已下的订单。这样虽然多占一点存储空间，但可以避免数据不一致带来的麻烦。

地址管理的另一个坑是不同平台的地址格式差异。微信小程序主要面向国内用户，但如果业务扩展到海外，情况就不一样了。比如香港、台湾的地址格式与大陆不同，有的地区没有区县概念，有的地区邮政编码是六位数。最初我没有考虑这一点，后来产品经理提出要加海外地址功能，我整个人都不好了。只能重新设计地址的数据结构，把省市区设为可选，并允许用户自定义区域名称。这个过程很痛苦，但也给了我教训：做任何功能都要留一点扩展余地，别把路走死了。

我想说，地址管理这事儿看似不起眼，却直接关系到用户的购物体验和物流效率。一个地址填错，包裹可能送不到；一个选择器卡顿，用户可能就流失了。我在这块花的时间比预想的多了一倍，但回头看，每一分投入都值得。小程序开发就是这样，细节决定成败。与其追求花哨的特效，不如先把这些基础功能打磨好。毕竟用户使用你的产品不是为了看动画多酷，而是为了解决问题。地址管理做好了用户可能不会夸你，但砸了用户肯定会骂你。所以，别嫌烦，所有该踩的坑一个都别漏。