Navicat不支持直接解析WKT/WKB，需先建空间类型表再用ST_GeomFromText批量插入，并严格匹配SRID；不支持Shapefile/GeoJSON导入，应改用ogr2ogr、shp2pgsql或QGIS。
Navicat 不直接解析 WKT/WKB，必须预处理字段类型
Navicat 本身不识别 POINT、POLYGON 等空间类型，导入时若源文件（如 CSV/Excel）含 WKT 字符串（如 "POINT(116.4 39.9)"），它会默认当作普通 TEXT 或 VARCHAR 导入，后续无法参与空间查询。你得先在目标数据库中建好带空间类型的表，再用 Navicat 的「追加」或「更新」方式写入——而不是依赖「导入向导」自动建表。
- 建表语句必须显式声明空间列，例如 MySQL：
CREATE TABLE locations (id INT, geom POINT SRID 4326); - CSV 中的 WKT 字符串不能带引号包裹后再导入（如
"'POINT(116.4 39.9)'"是错的），应为无引号裸字符串：POINT(116.4 39.9) - 确保 CSV 列顺序与目标表字段顺序一致，尤其空间列位置要对齐
用 INSERT + ST_GeomFromText 批量写入（MySQL / PostgreSQL 兼容写法）
Navicat 的「运行批量 SQL」功能比「导入向导」更可控。把原始数据整理成带 ST_GeomFromText 的插入语句，可绕过类型识别缺陷。
- MySQL 示例（SRID 必须显式指定）：
INSERT INTO locations (id, geom) VALUES (1, ST_GeomFromText('POINT(116.4 39.9)', 4326)), (2, ST_GeomFromText('LINESTRING(0 0, 1 1)', 4326)); - PostgreSQL（PostGIS）用
ST_GeomFromText同样有效，但注意：若目标列是GEOGRAPHY，需转成ST_GeogFromText - 大文件建议分批（500–1000 行/批），避免 Navicat 内存溢出或超时
从 Shapefile 或 GeoJSON 导入？别用 Navicat，换命令行或 QGIS
Navicat 完全不支持 Shapefile（.shp）、GeoJSON（.geojson）等地理格式的直接导入。试图拖入这类文件只会报错 Unsupported file format 或静默失败。
- MySQL 用户：用
ogr2ogr（GDAL 工具）转 Shapefile → MySQL：ogr2ogr -f "MySQL" MYSQL:"dbname,user=root,password=xxx" input.shp
- PostgreSQL + PostGIS 用户：优先用
shp2pgsql命令生成 SQL，再用 Navicat 执行该 SQL 文件 - 临时方案：用 QGIS 打开 GeoJSON，右键图层 → «导出» → «另存为» → 格式选 «PostgreSQL» 或 «MySQL»，QGIS 会自动调用对应驱动
导入后务必验证 SRID 和坐标系一致性
即使成功写入，geom 列看起来有值，也不代表能正确计算距离或画图——常见坑是 SRID 错配。比如用 WGS84 坐标（SRID 4326）却建了 SRID 0 的列，所有 ST_Distance 结果都失真。
- 检查当前值 SRID：
SELECT ST_SRID(geom) FROM locations LIMIT 1; - 修正错误 SRID（仅当确认数据坐标系正确时）：
UPDATE locations SET geom = ST_SetSRID(geom, 4326) WHERE ST_SRID(geom) = 0; - PostgreSQL 中若列定义为
GEOMETRY(POINT, 4326)，但插入时没指定 SRID，函数如ST_DWithin会直接报错，不是警告
