全国省市区数据下载后怎么更新编码层级和版本同步
全国省市区数据下载后，应先保存来源、地区代码、父级关系、层级和版本，再在临时表比较新旧差异。不要按名称直接覆盖生产数据，否则地区调整可能破坏历史订单、地址和统计口径。
为什么省市区数据必须带版本？
省市区数据既用于前端展示，也用于订单、CRM、配送和统计关联。只保存“省、市、区县”三个文本字段，遇到同名地区、名称调整或上下级关系变化时，很难解释旧记录属于哪一版数据。
民政部按年度公开县以上行政区划代码，例如 2022 年代码和 2023 年代码。年度页面分别提供代码与单位名称，说明来源年份本身就是解释数据的重要上下文。它不代表所有商业数据都按相同周期更新，实际同步频率仍要看数据来源和授权说明。
本地表应该保存哪些结构？
本地模型至少要表达“这条记录是谁、属于谁、处在哪一级、来自哪个版本”。可以按业务需要设计以下字段：
| 内部字段 | 用途 | 注意事项 |
|---|---|---|
region_id | 本系统稳定主键 | 不直接使用地区名称作为主键 |
source_code | 保存来源中的地区代码 | 代码格式以实际数据源为准 |
parent_id | 建立上下级关系 | 导入后检查父级是否存在 |
level | 区分省、市、县区等层级 | 不凭名称长度猜测层级 |
display_name | 保存当前展示名称 | 名称变化时保留变更记录 |
source_version | 标记来源批次或发布日期 | 用于差异比较、审计和回滚 |
active | 控制当前是否可选 | 停用记录不直接物理删除 |
这些是业务系统的建模字段，不是任何一个接口的固定返回结构。截至 2026 年 8 月 7 日，极速数据的全国省市县行政区划 API详情页列出了 id、parentid、depth、districtcode、areacode 和 zipcode 等返回字段。若使用该 API，可将当前字段逐项映射到内部模型；若拿到的是授权文件，则必须以实际文件字段为准，不能假定它与 API 完全相同。
新版本数据应怎样导入？
不要把新文件直接覆盖生产表。一次可回滚的同步可分为五步：
- 登记来源。 保存文件名、来源、获取时间、版本说明和文件校验值，让输入可追溯。
- 导入临时表。 验证必需字段、代码唯一性、字符编码、父子关系和层级值，失败时停止发布。
- 生成差异报告。 将记录分成新增、名称变化、父级变化、代码变化、停用和未变化。
- 复核高影响变化。 父级或代码变化可能影响区域规则、报表和地址匹配，不应静默自动覆盖。
- 切换版本并保留回滚。 验证通过后再更新当前版本，同时保留旧版本、差异记录和切换时间。
如果前端使用三级联动，可按 source_version 生成缓存键。后端切换数据后再刷新前端缓存，避免同一张表单同时使用两套层级关系。
历史地址为什么不能直接改成新名称？
订单、合同和客户档案中的地址反映业务发生时的信息。当前选择器可以使用新版本，但历史单据是否迁移应按企业规则处理。较清晰的做法是分开保存原始地址文本、当时的地区代码、来源版本和当前映射结果，让审计与新业务查询各有依据。
行政区划也不能替代详细地址解析。它解决层级和区域代码问题，门牌、楼栋、经纬度和配送可达性仍需地址服务、业务规则或人工确认。
数据文件进入同步流程前要确认什么？
先核对来源、授权范围、字段说明、发布日期、更新方式、完整包或增量包标识，以及是否允许缓存、内部使用或再分发。文件能够下载只说明技术上可以取得，不代表已经获得所有用途的授权。
极速数据的 API 与数据文件属于不同交付形态。上述行政区划页面只能证明在线 API 当前公开的接口和字段，不能证明账号自动拥有文件下载、缓存或再分发权益；需要文件时，应以实际购买页面、合同或交付说明为准。
总结
全国省市区数据更新的关键不是重新导入，而是保留来源版本、代码关系和差异记录。临时表验证、人工复核高影响变化、版本切换和历史地址双轨保存，能让地区调整不再直接破坏旧业务数据。
