PostgreSQL + PostGIS 是唯一靠谱的选择，因 SQLite 和 MySQL 不原生支持 GEOMETRY 类型解析，易报错；导入前须执行 CREATE EXTENSION IF NOT EXISTS postgis; 并确认 SELECT PostGIS_Version(); 有返回；注意 SRID 一致性与 psql 命令行导入更可靠。
PostgreSQL + PostGIS 是唯一靠谱的选择
纯 sqlite 或 mysql 导入含 geometry 字段的 sql 文件基本会失败——它们不原生支持空间类型解析，即使字段声明为 geometry，也会被当作文本或报错 type "geometry" does not exist。postgresql 配合 postgis 扩展是当前最稳定、标准兼容性最好的方案，其他数据库要么需定制解析器，要么丢弃空间语义只存 wkt 字符串。
导入前必须启用 PostGIS 扩展
即便已安装 PostGIS，新数据库里也不会自动启用扩展，直接导入含 ST_GeomFromText、GEOMETRY 类型定义的 SQL 会报错 function st_geomfromtext(unknown, integer) does not exist 或 type "geometry" does not exist。
- 连接到目标数据库后，先执行：
CREATE EXTENSION IF NOT EXISTS postgis;
- 如果 SQL 中用了地理坐标系（如 SRID 4326），建议同时启用：
CREATE EXTENSION IF NOT EXISTS postgis_topology;
- 确认是否生效：运行
SELECT PostGIS_Version();，有返回即表示加载成功
SQL 文件里常见的空间语法陷阱
很多导出的 SQL（比如从 QGIS、GeoPandas 或 pg_dump 生成）会包含带 SRID 的 WKT 或 EWKT，例如 SRID=4326;POINT(116.4 39.9)。PostgreSQL 默认接受这种写法，但以下情况容易翻车：
-
INSERT语句中直接写ST_GeomFromText('POINT(1 1)')而没指定 SRID → 插入后ST_SRID(geom)返回 0，后续空间计算可能出错 - 字段定义写成
geom GEOMETRY(Point, 4326)，但插入时用了ST_GeomFromText('POINT(1 1)')（无 SRID）→ PostgreSQL 会拒绝插入，报错Geometry SRID (0) does not match column SRID (4326) - 使用
pg_dump --inserts导出的 SQL 可能用ST_AsEWKT格式，如'SRID=4326;POINT(116.4 39.9)'，这种可直接导入；但若导出时没加--inserts，而是用二进制格式或自定义脚本拼接，很可能漏掉SRID=xxx;前缀
用 psql 导入比客户端工具更可控
很多 GUI 工具（DBeaver、pgAdmin）在处理大体积空间 SQL 时会截断、转义或静默跳过含函数调用的 INSERT 行，导致数据不全且无提示。命令行 psql 是最可靠方式：
- 确保文件编码为 UTF-8（含中文路径/注释时尤其关键），否则可能报错
invalid byte sequence for encoding "UTF8" - 执行：
psql -U username -d dbname -f /path/to/data.sql
- 若 SQL 文件很大，加
-v ON_ERROR_STOP=1让它在第一处错误就停下，方便定位问题行：psql -v ON_ERROR_STOP=1 -U username -d dbname -f data.sql
- 避免用
source或重定向（psql ），它们无法传递变量或正确处理多行字符串
空间数据的“形状”本身没问题，但导入过程里 SRID 匹配、扩展启用、SQL 解析边界这三处最容易卡住——少检查一步，就得多花半小时翻日志。
