美国地址格式：门牌、州缩写与邮编扩展码

美国地址格式表面上是所有国家里最好写的一种：门牌号加街名，一行城市与州缩写，再加邮编，看起来没有歧义。真正开始做校验就会发现细节不少——单元号放在哪一行、州缩写能不能自己缩、邮编后面那四位是什么、军用地址为什么长得跟普通地址完全不同。这篇把这几件事一次说清，读完你能给自己的美国地址表单列出一份完整的错误清单。

一段美国地址由哪几部分组成

标准的写法人人都见过：第一行是门牌号加街道名，后面可以跟一个单元号；第二行是城市名、两位州缩写和五位邮编；州与国家在最后。姓名和公司名在上方，属于收件人信息，不是地址本身。

几个容易被忽略的点：街道名里常带方向词与街道类型词，方向词可能出现在街名前后两端，位置不同代表不同方向的路段，不能随意调换。楼栋、公寓、套房这类单元信息不属于街道行的内容，它有自己的标记写法，通常单独跟在街道行末尾或者单独一行。

单元号为什么不该并进街道行

把单元号写进街道行，看着省了一行，代价是后续很难把它拆出来。快递面单、地域统计、去重比较都希望街道行只包含道路信息，单元号混进去以后，同一栋楼的不同住户会被当成不同的街道地址，同一个地址在不同用户手里又会写成好几种样子。

更稳妥的做法是让单元号有独立字段。如果表单要为海外用户保留一行自由文本，那就把单元号放在末尾并允许留空。要注意的是，公寓、套房与楼层这些概念在不同国家并不一一对应，硬用一个字段名去套所有国家，标签会误导用户。这类语义问题在国际地址格式里讲得更细。

州缩写可以自己缩吗?

不可以。州有官方的两位字母缩写，用错了地址就读不通。常见的错误是把州名全称的前两个字母拿来当缩写，或者按自己的习惯缩到二到三个字母，这两种做法都会产出系统不认识的代码。

对开发者来说这意味着表单里的州不该是自由文本输入，而应当是一个从官方缩写列表生成的下拉选项。用户按州全称搜索、系统存两位缩写，是把易用性和数据规范同时满足的做法。国家层面的编码方案另有一套体系，见ISO 国家代码与行政区代码；两套代码不要互相借用。

五位邮编后面的四位扩展码是什么?

五位邮编负责定位到一个投递区域，追加的四位扩展码进一步缩小到更小的范围，比如一段街区、一栋楼甚至一个机构。它不是每一位都必填，很多表格只收前五位，写收件地址时只写五位也完全可以投递。

对表单的影响有两处。一是别把邮编字段限制成只能输入五位，否则用户填了扩展码会被静默截断。二是校验时要把扩展码设为选填，并且允许中间出现连字符。至于邮编与州不匹配，这是美国地址数据里最经典的一类错误，也是测试最该覆盖的一类。

军事地址和领地地址为什么也会出现

存在专门服务于海外驻军的地址写法，它们使用固定的城市名与一组两位的州式代码，还带有更细的投递标识，外观上和普通美国地址很像但不是一回事。另外，海外领地虽然不在五十个州里，却有正规的两位代码和邮编体系，填州的下拉框如果不包含它们，这些用户根本没法提交表单。

这两类地址常被当作不存在，直到线上收到投诉才补。更省事的做法是在设计表单时就把官方给出的完整代码集合纳入选项，而不是只列五十个州。军事地址与领地地址都值得在样本集里各留一条，用生成器选美国就能取到。

哪些错误最值得先测

下面这份清单按出现频率排列，覆盖了大多数线上事故的来源：

把这几条做成固定的回归用例，比每次上线前临时想测试点可靠得多。

清单里前两条属于同一个根源：把本该结构化的字段交给了自由输入。要减少这类问题，可以让输入引导承担一部分判断——用户在州字段里输入几个字母时给出候选项，在邮编与州明显冲突时提示而不是拒绝。引导的作用是降低出错概率，而不是把判断权从用户手里拿走。

给开发者：字段设计与边界值

第一，州用下拉选项而不是文本框，取值来自官方两位缩写列表，并且包含领地与军事代码。城市与邮编不要做强制联动校验，真实数据里存在跨城市取邮编的合理情况，硬性拦截会挡下合法输入。

第二，邮编按字符串存，允许五位与九位两种长度，允许连字符，并按州做范围提示而不是硬性拒绝。

第三，街道行长度上限留足空间，方向词、街道类型词与长路名叠在一起时会很长，截断会让地址失去可定位性。

第四，准备边界样本：最短门牌号、带方向词的街名、含单元号的地址、只有五位邮编与带扩展码的邮编、军事地址、领地地址、以及邮编与州不一致的样本。测试数据集的组织方式见测试固定装置里的地址数据，表单层面的用例清单见收货地址表单的测试用例。上面这些样本都只用于测试，不能投递。

下一步

要一批结构与字段关系都对的美国地址，用随机地址生成器选美国批量生成，城市、州与邮编取自同一条记录，可以直接用来验证你的表单会不会把合法地址误判成非法。上线前建议把上面那张错误表逐条跑一遍真机输入，尤其是粘贴整段地址与自动填充这两条路径——事故大多出在用户没有亲手输入的时候。