国际化地址表单设计指南：别假设每个国家都有「省」

一、行政层级到底差在哪里

下面这张表把几个典型市场的地址层级放在一起对比。注意它们的层数不同、必填项不同， 甚至同一个字段的语义也不同——中国的「市」是行政区划，英国的 post town 则是邮政投递单元， 两者不能简单对齐。

从工程角度看，比较稳妥的抽象是把二级行政区统一命名为 administrativeArea， 把三级统一命名为 locality， 再在界面上按国家换成用户熟悉的标签：中国显示「省」，美国显示 State，日本显示「都道府県」， 英国干脆隐藏。数据库层保持稳定，展示层做本地化，这样后续新增国家不需要改表结构。

二、六个最常见的设计错误

三、按国家驱动的表单结构

与其在组件里写一堆 if (country === "US")， 不如把每个国家的差异抽成配置数据。一个最小可用的配置大致是这样：

type AddressFieldConfig = {
  // 字段渲染顺序，未出现的字段不渲染
  order: FieldKey[]
  // 各字段的本地化标签
  labels: Partial<Record<FieldKey, string>>
  // 必填字段集合
  required: FieldKey[]
  // 二级行政区是否为固定枚举（如美国州列表）
  administrativeAreaOptions?: { code: string; name: string }[]
  // 邮编的宽松格式提示（仅用于提示，不做硬拦截）
  postalCodeHint?: string
}

const US: AddressFieldConfig = {
  order: ["name", "line1", "line2", "locality",
          "administrativeArea", "postalCode"],
  labels: { administrativeArea: "State", locality: "City",
            postalCode: "ZIP Code" },
  required: ["name", "line1", "locality",
             "administrativeArea", "postalCode"],
  administrativeAreaOptions: US_STATES,
  postalCodeHint: "12345 或 12345-6789",
}

const SG: AddressFieldConfig = {
  order: ["name", "line1", "line2", "postalCode"],
  labels: { postalCode: "Postal Code" },
  required: ["name", "line1", "postalCode"],
  postalCodeHint: "6 位数字",
}

这个模式的好处是：新增一个国家等于新增一条配置，不需要碰渲染逻辑； 测试时也可以直接遍历所有配置，验证每个国家的表单都能正常渲染与提交。 Google 开源的 libaddressinput 数据集、以及各类地址元数据库都采用了类似的思路， 如果不想自己维护，可以直接引用现成的元数据。

四、别忘了 autocomplete：一行属性省下十次输入

HTML 规范定义了一组地址相关的 autocomplete 词元，浏览器和密码管理器依赖它们来判断 「这个框该填什么」。把它们标对，用户点一下就能自动填完整个地址；标错或不标， 自动填充就会把电话填进邮编框。这是投入产出比最高的一项优化。

五、校验：宽进严出，而不是宽出严进

六、上线前的自检清单

1. 用不带二级行政区的国家（如新加坡）跑一遍全流程，确认没有必填拦截。
2. 用不使用邮编的国家（如阿联酋、香港）跑一遍，确认邮编字段被隐藏或标记为选填。
3. 输入含变音符号、假名、汉字的地址，确认从表单到数据库到打印模板全链路无乱码、无截断。
4. 把每一行地址填到字段长度上限，观察是否静默截断。
5. 在移动端浏览器上测试自动填充，确认各字段落位正确。
6. 切换国家两三次后再提交，确认残留的旧枚举值不会被写库。
7. 用屏幕阅读器过一遍，确认每个 label 都与输入框正确关联。