简介：面向开发、数据分析与地理信息相关从业者的全国行政区划代码数据集，依据GB/T 2260标准整理，覆盖省、市、县、乡镇四级区划，共约4.6万条记录，可用于数据库建表、地区字典维护、统计分析及GIS项目的基础数据准备。压缩包共4个文件，约5.01MB，分别提供SQL脚本、Access数据库、TXT文本和XLSX表格：SQL可直接导入MySQL快速建表，mdb便于无SQL环境查看，TXT与XLSX则适合Excel读取、筛选和二次加工。已有1105人学习下载，说明其在行政区划数据整理场景中具有一定参考价值。数据为2017年版本，使用者可据此获得较完整的六位行政区划编码、层级关系与名称对照，同时也需留意区划调整带来的时效性限制，适合做历史数据复现或基础字典搭建。
1. 拿到一份 SQL 版全国行政区划代码，先想清楚它替你省了哪一步
上个月帮朋友的公司做一套后台，注册页要选地区，产品经理甩过来一句「三级联动，数据要准」。真动手才发现麻烦不在前端，而在数据本身：全国行政区划代码这套东西每年都在动，撤县设区、改名、编码合并，随手从网上抄一份 GB/T 2260 的 CSV，导入之后大概率是一半父子关系对不上。这次拿到手的是打包成 SQL 脚本的全国行政区划代码库，直接source就能出表，省掉的正是「找数据 + 对齐层级 + 补父级」这一段最枯燥也最容易出错的活。它适合三类人：做后台表单联动的、做数据清洗要按地区聚合的、以及需要在离线环境里维护一份地区字典的。下面按「数据结构怎么设计的、脚本怎么跑、查询怎么写、哪里会翻车、二次开发怎么接」顺着拆一遍。
2. 数据模型拆解：GB/T 2260 编码规则与表结构设计
先把编码这件事说透，否则后面所有查询都是猜。GB/T 2260 是行政区划代码的国家标准，主体是 6 位数字，按「省 2 位 + 地 2 位 + 县 2 位」分段递进。很多 SQL 脚本在这个基础上还会额外提供 9 位或 12 位的扩展码（统计用区划代码），扩展段对应乡级、村级。你手上这份资源到底给到哪一级，导入前先head看一眼源文件最稳妥。
2.1 六位编码的分段含义与层级判定
理解分段规则之后，层级其实是「算出来的」而不是「查出来的」。前 2 位非零、后 4 位全零，就是省级单位；前 4 位非零、后 2 位为零，就是地级单位；6 位全非零，就是县级单位。所以level字段本质是一个冗余字段，用来换查询性能。
-- 从编码本身推导层级，用于校验脚本里的 level 字段有没有写错 SELECT code, name, CASE WHEN RIGHT(code, 4) = '0000' THEN 1 -- 省级：后四位全零 WHEN RIGHT(code, 2) = '00' THEN 2 -- 地级：后两位为零 ELSE 3 -- 县级：六位占满 END AS derived_level, level AS stored_level FROM region_dict WHERE level <> CASE WHEN RIGHT(code, 4) = '0000' THEN 1 WHEN RIGHT(code, 2) = '00' THEN 2 ELSE 3 END;这段 SQL 的核心是拿「推导层级」和「存储层级」做对比，返回的就是脏数据。RIGHT(code, 4)取后四位判断是否全零，比用LIKE '%0000'更直白也不会被排序规则影响。参数上唯一要注意的是code必须是定长的CHAR(6)或至少保证没有前后空格——源文件里带\r或全角空格是这类数据集的经典毛病，导入时用TRIM()或LOAD DATA的字段处理兜住。
如果脚本提供的是 12 位扩展码，判定逻辑就往后顺延：后 6 位全零是省级，后 4 位全零是地级，后 2 位全零是县级，其余是乡级。这个分支建议单独写一个视图，别在主表上堆一堆CASE WHEN。
2.2 表结构：一棵自关联树，还是一张扁平字典
市面上的做法基本两种。第一种是自关联树，只存code / name / parent_code，层级靠递归查；第二种是扁平字典，把province / city / county三列直接拍平在一行里，查询极快但更新很痛。这份资源我倾向按「主表存树 + 视图拍平」组合着用。
CREATE TABLE region_dict ( code CHAR(6) NOT NULL COMMENT 'GB/T 2260 六位行政区划代码', name VARCHAR(64) NOT NULL COMMENT '区划名称', short_name VARCHAR(32) DEFAULT NULL COMMENT '简称，用于前端展示', parent_code CHAR(6) DEFAULT NULL COMMENT '父级编码，省级为 NULL 或 000000', level TINYINT NOT NULL COMMENT '1省 2地 3县', full_path VARCHAR(255) DEFAULT NULL COMMENT '冗余全路径，形如 省/市/县', is_active TINYINT NOT NULL DEFAULT 1 COMMENT '1在用 0已撤销', version_tag VARCHAR(16) DEFAULT NULL COMMENT '数据版本标记，如 2024A', PRIMARY KEY (code), KEY idx_parent (parent_code), KEY idx_level_active (level, is_active), KEY idx_name (name) ) ENGINE = InnoDB DEFAULT CHARSET = utf8mb4 COLLATE = utf8mb4_general_ci;逐列说一下取舍。code用CHAR(6)而不是INT，因为编码有前导零语义，且永远不会有算术运算，定长字符在索引里也更省。parent_code允许 NULL 是为了兼容省级节点——有些脚本给省级父级填'000000'，有些直接留空，导入前统一成一种，别两种混着来，否则LEFT JOIN会漏。full_path是明显的冗余，但前端做「省 / 市 / 县」面包屑、后端做报表分组时它值这个存储成本。
is_active这一列是我强烈建议保留的。行政区划的「撤销」在业务上不等于「删除」，历史订单里的地址还引着旧编码，物理删掉就等着报表缺行吧。常见的做法是把is_active = 0的节点留着，前端下拉框过滤，历史数据查询不过滤。
提示：如果脚本原本没带
is_active、version_tag这类运维字段，导入后自己ALTER TABLE补上比改脚本安全，后续换版本时这两列是 diff 的基础。
2.3 主键、索引与字符集：几个容易忽略的默认值
字符集这块翻车的人不少。源文件如果是 GBK 编码（老数据包很常见），直接往 utf8mb4 的表里灌，名称列会变成一堆问号或者乱码，而且不报错。稳妥的流程是先SHOW VARIABLES LIKE 'character_set_%'确认连接字符集，再在LOAD DATA里显式写CHARACTER SET。表一级用utf8mb4，排序规则选utf8mb4_general_ci就够，区划名称里出现生僻字的概率不高，但如果用的是 12 位扩展码且包含乡镇名，utf8mb4_0900_ai_ci在 MySQL 8.0 上对多音字排序更合理一点。
索引方面，主键在code上是必须的，idx_parent支撑「拿某省下面所有市」这类查询，idx_level_active服务「一次性拉全部县级」的字典预热。我一般不会在full_path上建索引，除非有明确的模糊搜索需求——真要做名称搜索，用name上的前缀索引或者干脆接一个全文/搜索引擎更合适。
还有一个隐性坑：code是CHAR(6)时，MySQL 的比较默认会忽略尾部空格，但如果某个脚本把编码存成了VARCHAR且混进了空格，'1101 '和'1101'在LEFT JOIN时可能匹配上也可能匹配不上，取决于版本和排序规则。所以导入后的第一件事就是跑一遍WHERE code <> TRIM(code)，把带空格的捞出来。
3. 导入落地：从脚本到可查询数据库的完整过程
数据模型清楚之后，跑起来这件事其实不复杂，难的是「跑完之后你怎么确信它是对的」。这一章按建表、导数据、体检、查询四步走，每一步都给可复制的命令。
3.1 建表与脚本执行顺序
脚本包里通常不止一个.sql文件，常见组合是「建表语句 + 数据插入语句」，或者「建表 + CSV 数据文件」。先看清单再动手，ls -lh看大小，几万行以内的INSERT语句可以直接source，几十万行的就该走LOAD DATA了。
# 1) 建库（字符集一定要显式指定，别依赖服务器默认值） mysql -uroot -p -e "CREATE DATABASE IF NOT EXISTS region_db \ DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;" # 2) 先只跑结构，不跑数据，确认表建对了 mysql -uroot -p region_db < schema.sql # 3) 再灌数据；如果是大文件，加 --max_allowed_packet 防截断 mysql -uroot -p --max_allowed_packet=64M region_db < data.sql # 4) 立刻看行数和层级分布，别等写完业务代码才发现少了一半 mysql -uroot -p region_db -e "SELECT level, COUNT(*) FROM region_dict GROUP BY level;"命令本身没什么玄学，值得说的是顺序。先跑结构再灌数据，好处是灌数据失败时表结构还在，可以反复重试；如果结构和数据混在一个文件里，中途报错你很难判断是 DDL 的问题还是某一行数据的问题。--max_allowed_packet这个参数在导入大INSERT语句时经常是罪魁祸首，默认 4M/16M 很容易被一条几万 value 的INSERT撑爆，报错信息是Packet too large，看到这个先加参数再说。
如果资源给的是 CSV 而不是 SQL 插入语句，用下面这段：
LOAD DATA LOCAL INFILE '/path/to/region.csv' INTO TABLE region_dict CHARACTER SET utf8mb4 FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"' LINES TERMINATED BY '\n' IGNORE 1 LINES (code, name, parent_code, level) SET is_active = 1;FIELDS TERMINATED BY和OPTIONALLY ENCLOSED BY要按源文件实际格式调，Windows 导出的文件行尾是\r\n，这时LINES TERMINATED BY '\n'会让每行末尾多一个\r，表现为最后一个字段带不可见字符——名称看不出来，code一比较就出问题。改成LINES TERMINATED BY '\r\n'或者在SET里对字段做TRIM(TRAILING '\r' FROM ...)。LOCAL关键字要求客户端开启local_infile，服务端没开的话会直接报错，换成服务端路径导入即可。
3.2 导入后的三步体检
行数对不上是最轻的病，父子关系断了才是要命的。我固定跑三组检查，加起来不到十秒。
第一组，看编码长度分布和重复：
-- 长度分布：正常应该只有一个长度值（6 或 12） SELECT CHAR_LENGTH(code) AS len, COUNT(*) AS cnt FROM region_dict GROUP BY CHAR_LENGTH(code); -- 重复编码：主键约束下不该有结果，但如果导入时做过 IGNORE，可能静默丢行 SELECT code, COUNT(*) FROM region_dict GROUP BY code HAVING COUNT(*) > 1;第二组，找孤儿节点——父级编码在表里不存在：
SELECT c.code, c.name, c.parent_code FROM region_dict c LEFT JOIN region_dict p ON c.parent_code = p.code WHERE c.parent_code IS NOT NULL AND c.parent_code <> '000000' AND p.code IS NULL;这段是标准的自连接反查。LEFT JOIN之后p.code IS NULL说明右表没匹配上，也就是父级缺失。注意要排除省级的哨兵值，否则每个省都会被当成孤儿报出来，白白吓自己一跳。
第三组，看层级分布是否合理：
SELECT level, COUNT(*) AS cnt, MIN(code) AS min_code, MAX(code) AS max_code FROM region_dict WHERE is_active = 1 GROUP BY level;正常情况下省级几十个、地级三百多、县级两千多，量级一眼就能看出对不对。如果县级数量和地级数量差不多，多半是源数据只到地级，或者层级字段整体错位了。
3.3 常用查询：按前缀取子树、按层级取平铺
数据干净之后，日常查询其实就那么几种。第一种，给一个省级前缀，取它下面所有地级：
-- 参数：@prov_prefix 传两位省级前缀，如 '11' SET @prov_prefix = '11'; SELECT code, name FROM region_dict WHERE code LIKE CONCAT(@prov_prefix, '%') AND level = 2 AND is_active = 1 ORDER BY code;LIKE CONCAT(@prefix, '%')这种「常量前缀 + 通配符」的写法能吃到code上的索引，因为前缀是确定的。但要注意CONCAT在部分版本里会让优化器放弃索引，稳妥写法是把拼接放到应用层，直接传'11%'进去，或者用范围条件code >= '110000' AND code < '120000'——范围写法对索引最友好，代价是要自己算上界。
第二种，一次取三级拍平，给前端做静态 JSON：
SELECT p.code AS prov_code, p.name AS prov_name, c.code AS city_code, c.name AS city_name, d.code AS dist_code, d.name AS dist_name FROM region_dict p JOIN region_dict c ON c.parent_code = p.code AND c.level = 2 JOIN region_dict d ON d.parent_code = c.code AND d.level = 3 WHERE p.level = 1 AND p.is_active = 1 ORDER BY p.code, c.code, d.code;三个自连接，数据量在万级以内毫无压力。如果嫌这个查询每次都要跑，把它物化成一张region_flat表，换版本时重建一次，前端接口直接SELECT *就行。
4. 核心脚本逐段讲：层级查询、前缀匹配与版本 diff
前面都是能用就行，这一章讲的是「用久了会疼」的地方。递归、索引失效、版本对比，这三块写不好，后面维护成本会翻倍。
4.1 递归 CTE 拼出完整路径
full_path这个字段如果脚本没给，得自己算。MySQL 8.0 的WITH RECURSIVE是标准解法：
WITH RECURSIVE tree AS ( -- 锚点：所有省级节点，路径从自己开始 SELECT code, name, parent_code, 1 AS lvl, CAST(name AS CHAR(255)) AS path FROM region_dict WHERE level = 1 UNION ALL -- 递归：子节点把自己的名字接到父节点路径后面 SELECT c.code, c.name, c.parent_code, t.lvl + 1, CONCAT(t.path, '/', c.name) FROM region_dict c JOIN tree t ON c.parent_code = t.code WHERE t.lvl < 4 -- 防御性上限，避免脏数据造成无限递归 ) SELECT code, path FROM tree ORDER BY code;锚点部分是递归的起点，必须能筛出没有父级的那些行，否则整棵树无从展开。递归部分每轮把子节点挂到上一轮结果上，lvl做深度计数，path做字符串累加。CAST(name AS CHAR(255))这步容易被忽略——CTE 的列类型由锚点决定，如果不显式加宽，MySQL 可能按第一行的实际长度推断，深层路径拼到一半被截断。t.lvl < 4是我自己的习惯，脏数据里偶尔出现父子互相指向的行，没有这个上限，查询会一直跑到cte_max_recursion_depth（默认 1000）才报错，日志里一片红。
这段查完，拿结果去UPDATE region_dict SET full_path = ...回填。回填时按code关联，别按名称关联，重名的区划不在少数，按名字更新是经典的翻车姿势。
4.2 前缀匹配别写成函数包字段
WHERE LEFT(code, 4) = '1101'和WHERE code LIKE '1101%'结果一样，性能差一个数量级。前者把字段包在函数里，索引直接失效，几十万行看似能忍，一旦这张表跟别的表JOIN起来，全表扫描会被放大成灾难。
-- 反例：函数包字段，索引失效 SELECT * FROM region_dict WHERE LEFT(code, 4) = @prefix4; -- 正例一：常量前缀 LIKE，可走索引 SELECT * FROM region_dict WHERE code LIKE CONCAT(@prefix4, '%'); -- 正例二：范围查询，索引利用率最高 SELECT * FROM region_dict WHERE code >= @prefix4 AND code < @next_prefix4;第二个正例需要一个「上界」参数@next_prefix4，计算方式是对前缀末位做进位，比如四位前缀的下一个区间起点就是末位加一。这个计算放在应用层做比放在 SQL 里做清晰得多，Java 里几行字符串处理，Python 里str(int(prefix) + 1).zfill(4)就完事。真要在 SQL 里算，用CONCAT(LEFT(@prefix4, 3), CHAR(ASCII(RIGHT(@prefix4, 1)) + 1))，可读性极差，不推荐。
另一个需要留心的点：如果code列在源脚本里是VARCHAR而不是CHAR，LIKE '11%'比的是字符串前缀，语义正确；但如果有历史遗留的空格，' 110000'不会匹配。导入阶段的那次TRIM检查，在这里体现价值。
4.3 版本 diff：新增、撤销、更名怎么捞出来
行政区划一年调一次，业务系统不可能每次全量重灌——历史订单关联的旧编码一旦被删，报表直接缺数据。正确的姿势是每年把新版数据导入一张临时表，跟老表对比出差异，只做增量更新。
-- region_old / region_new 结构相同，均为 code + name + is_active -- 三类差异一次查出：新增、撤销（新版中不存在）、更名 SELECT n.code, n.name AS new_name, o.name AS old_name, CASE WHEN o.code IS NULL THEN 'add' WHEN n.code IS NULL THEN 'remove' WHEN n.name <> o.name THEN 'rename' END AS diff_type FROM region_new n LEFT JOIN region_old o ON n.code = o.code WHERE o.code IS NULL OR n.name <> o.name UNION ALL SELECT o.code, NULL, o.name, 'remove' FROM region_old o LEFT JOIN region_new n ON n.code = o.code WHERE n.code IS NULL;前半段捞「新增」和「更名」，后半段捞「删除」。CASE里先判o.code IS NULL，是因为这一支里新增行一定存在，判断顺序错了会把新增误标成更名。UNION ALL而不是UNION，是为了避免对大结果集做去重排序。
拿到 diff 之后，新增的直接INSERT，更名的UPDATE name，删除的不要DELETE，改成UPDATE is_active = 0。这一条是血泪经验：某次做数据同步，把撤销的区划物理删了，半个月后财务对账发现有一批历史订单的地区字段关联不上，只能从备份里捞。从那以后is_active成了强行要求，删除操作在区划表上是禁止的。
注意：更名的情况要区分「编码不变只改名」和「编码变更（撤并）」。后者在 diff 里表现为一删一增，需要人工确认映射关系，脚本没法自动推断，别指望自动搞定。
5. 避坑与排查：导入和查询里最容易翻车的几处
这一章是我踩过的坑的合集，按「现象 → 原因 → 解决」记，遇到问题先来这里对号入座。
5.1 导入阶段的两个高频翻车点
现象一：导入提示成功，但SELECT COUNT(*)比源文件行数少一截。
原因通常是INSERT IGNORE或ON DUPLICATE KEY UPDATE在默默吞掉冲突行。区划数据集里偶尔出现同一编码对应两条记录（历史遗留或合并时的脏数据），主键约束一拦，那条就没了，而且不报错。另一种可能是sql_mode里开了STRICT_TRANS_TABLES，某个字段超长或类型不符直接整行拒收。
解决方式：导入前先关掉IGNORE，让它报错，SHOW WARNINGS看具体哪一行；导入后拿源文件行数和COUNT(*)做一次硬比对，不相等就按code做 left join 找出缺哪些。类型超长的问题（比如名称列给了VARCHAR(20)但有个长名字）提前把字段放宽到VARCHAR(64)更省事。
现象二：中文名全是问号，或者排序结果不对。
前者是字符集链路断在了某一环：客户端连接是 latin1、源文件是 GBK、表是 utf8mb4，三者任意一个不匹配都会出乱码，而且 MySQL 常常不报错。后者多半是排序规则选成了utf8mb4_bin，按字节比较，结果跟人的预期不一致。
解决方式：SHOW VARIABLES LIKE 'character_set_%'确认client、connection、results三项；LOAD DATA里显式写CHARACTER SET gbk或utf8mb4覆盖自动推断；导入后跑一遍SELECT name FROM region_dict WHERE name LIKE '%?%'，有结果就是乱码，重灌。语句前面加SET NAMES utf8mb4;也是个便宜保险。
5.2 查询阶段的三个隐蔽问题
现象三：LEFT JOIN查子级时，本省的数据跑到了别的省下面。
原因几乎都是parent_code的类型或值不一致：父表code是CHAR(6)，子表parent_code是VARCHAR(6)，某些行末尾带空格；或者省级父级有人填NULL、有人填'000000'、有人填''，三种写法在JOIN时的行为各不相同。
解决方式：建表时两张关联列保持完全一致的类型和字符集；导入后统一父级哨兵值，建议省级统一为NULL并在应用层判空，或者统一为'000000'并在表上加 CHECK 约束。别两种并存。
现象四：递归查询跑着跑着报Recursive query aborted after 1001 iterations。
原因是数据里存在环，A 的父级是 B、B 的父级又是 A，或者某行parent_code = code自指。这种脏数据在手工维护的 Excel 转 SQL 里挺常见。
解决方式：跑之前先用一句 SQL 排查自指——SELECT * FROM region_dict WHERE code = parent_code；环状引用用递归 CTE 加深度上限兜住（前一章那个t.lvl < 4），同时在应用层把cte_max_recursion_depth调小到 10 以内，让问题尽早暴露而不是跑满 1000 轮。
现象五：前端下拉框里出现了已经撤销的区划，用户选了一个不存在的地址。
原因是查询语句忘了加is_active = 1，或者脚本在导入新版本时把旧数据混进了同一张表却没有标记状态。
解决方式：给「前台展示用」和「历史数据回查用」分别建视图，前台视图固定带is_active = 1和version_tag = 当前版本，业务代码只允许查视图不允许查基表。这条约束听着麻烦，但能避免 90% 的「为什么列表里多了个不存在的县」这类问题。
6. 二次开发：把静态字典接进业务系统
脚本跑通只是第一步，真正的工作量在于让它变成业务系统里一个「不用操心」的组件。这一章讲三个改造点，都是接了十几个项目之后沉淀下来的固定套路。
6.1 封装成只读字典服务
区划数据是典型的读多写少，最适合做成只读服务。我的做法是不让业务代码直接碰数据库，中间垫一层RegionService，对外只暴露四个方法：按编码取单条、按父级取子列表、按层级取全量、按编码取完整路径。
# 极简版字典服务，缓存层用进程内字典，适合单机部署 class RegionService: def __init__(self, conn): self._conn = conn self._cache = {} # code -> row self._children = {} # parent_code -> [rows] self.reload() def reload(self): with self._conn.cursor() as cur: cur.execute(""" SELECT code, name, parent_code, level, full_path FROM region_dict WHERE is_active = 1 """) rows = cur.fetchall() self._cache = {r[0]: r for r in rows} self._children = {} for r in rows: self._children.setdefault(r[2], []).append(r) def children_of(self, parent_code): # 未命中返回空列表而不是 None，调用方少一层判空 return self._children.get(parent_code, []) def path_of(self, code): row = self._cache.get(code) return row[4] if row else Nonereload()一次性把全量数据拉进内存，万级数据占几十 MB，对单机服务完全可以接受。_children这个反查字典是关键，把「按父级取子级」从一次 SQL 变成一次哈希查找。children_of返回空列表而不是None，是为了让调用方少写一层判空——这种小约定在多人协作里能省不少事。如果数据量再大或者多实例部署，把这层换成 Redis Hash，键设计成region:children:{parent_code}，reload时整体重建。
6.2 版本化与缓存刷新
每年新版数据发布，服务不能停机重灌。我一般用「双表 + 版本标记」的做法：region_dict上带version_tag，新版本导入时先写version_tag = '2025A'，跑完 diff 和体检确认无误，再一次性把服务的缓存指向新版本，老版本的记录保留一段时间供历史查询。
| 改造点 | 具体做法 | 注意 |
|---|---|---|
| 版本标记 | 每行带version_tag，查询默认过滤当前版本 | 老版本不要立刻删，留一个季度 |
| 缓存刷新 | 提供/admin/region/reload内部接口，手动触发 | 加个鉴权，别裸奔 |
| 灰度切换 | 新旧版本并存，配置项控制读哪张表 | 出问题能秒回滚 |
| 变更通知 | diff 结果落一张region_change_log表 | 下游系统可订阅 |
刷新接口这块我吃过一次亏：直接在业务高峰期调了reload()，全量查询把数据库连接池打满，接口超时一片。后来改成先查到一个临时字典对象，构建完成后再做一次原子替换引用，数据库压力就从「瞬时高峰」摊平成了「后台慢慢查」。
6.3 校验规则落到写入侧
最后一步，也是最容易被跳过的一步：在业务写入口做区划合法性校验。用户注册填的地址、订单里的收货地区，都应该在落库前检查编码是否存在于当前版本的字典里、层级是否正确（比如县级编码不能直接挂在省级下面）。
-- 落库前的校验：编码存在、在用、且父子层级连续 SELECT 1 FROM region_dict c JOIN region_dict p ON c.parent_code = p.code WHERE c.code = ? AND c.is_active = 1 AND p.is_active = 1 AND c.level = p.level + 1;这条语句返回空就拒绝写入。加上p.is_active = 1是为了挡住「子级还在用但父级已撤销」的脏情况，实际数据里确实出现过。参数就一个待校验的编码，成本极低，但能挡掉大部分前端传错值、或者用户提交了过期页面缓存的情况。
我现在的习惯是：任何一张字典类表接入业务之前，先写三样东西——只读服务封装、版本切换开关、写入侧校验 SQL。三样齐全了才允许业务方调用，缺一样后面必出问题。行政区划这种一年一动、动起来还带着历史数据牵连的数据尤其如此，图省事直接SELECT *糊上去，等某天发现订单表里挂着一批查不到名字的地区编码，返工的成本远高于当初多写的这几十行。
希望帮到你。
本文还有配套的精品资源，点击获取
