简介postgis-bundle-pg14-3.5.0x64.zip 是面向 PostgreSQL 1464 位用户的 PostGIS 3.5.0 空间数据库扩展安装包适合需要为数据库增加地理空间数据存储、查询与分析能力的开发者与系统管理员。PostGIS 遵循 OGC 与 SFSQL 规范支持点、线、多边形等几何类型及空间索引、空间关系与空间操作函数可用于地图服务、位置分析、城市规划、环境监测、交通物流与灾害管理等场景。压缩包共 1335 个文件约 130.92MB以 951 个 sql 脚本、79 个 dll 动态库、75 个 csv 示例数据、50 个 tif 栅格影像及 control、pl、json、xml 等配置与元数据文件为主涵盖库文件、文档、示例数据与安装脚本解压后按脚本与配置更新数据库即可完成扩展集成。目前已有 95 人学习下载适合希望将 PostgreSQL 快速升级为成熟 GIS 数据库解决方案的读者参考使用。1. postgis-bundle-pg14-3.5.0x64.zip 到底是什么离线装 PostGIS 前先搞清的三件事如果你在 Windows 上给 PostgreSQL 14 装 PostGIS多半会撞上这个文件名postgis-bundle-pg14-3.5.0x64.zip。它不是一个安装程序而是一个把 PostGIS 3.5.0 针对 PostgreSQL 14、64 位 Windows 编译好的二进制包解压后覆盖到 PG 安装目录即可生效。名字里每个字段都是硬约束pg14对应 PostgreSQL 14 的主版本3.5.0是 PostGIS 版本x64是 64 位架构bundle表示它把依赖库一起打包了。很多人搜「postgis安装失败」八成就是版本对不上或者解压路径放错。这篇笔记按「先确认环境、再解压部署、最后验证排错」的顺序讲清楚适合需要在离线或内网 Windows 机器上给 PG14 加空间数据能力的后端和 GIS 工程师。2. 版本匹配与依赖确认装之前先把地基验一遍2.1 为什么 pg14 和 3.5.0 这两个数字不能错PostGIS 是作为 PostgreSQL 的扩展extension运行的它的二进制文件必须和 PostgreSQL 的主版本号严格对应。PostgreSQL 每个大版本会改变扩展的 ABI应用二进制接口用 pg13 编译的 PostGIS 动态库塞进 pg14 的目录轻则CREATE EXTENSION postgis报「could not load library」重则服务直接起不来。所以postgis-bundle-pg14-3.5.0x64.zip里的pg14不是可选项是硬门槛。先确认你机器上的 PostgreSQL 到底是什么版本。打开命令行用 psql 查# 连上数据库后执行看服务端版本 psql -U postgres -c SELECT version();输出里会带类似PostgreSQL 14.11, compiled by Visual C build 1914, 64-bit的字样。重点看三处主版本是不是 14、是不是 64-bit、编译工具链。如果显示的是 32-bit那这个 x64 包直接不能用得换 32 位版本。如果主版本是 15 或 16也别硬上去找对应 pg15、pg16 的 bundle 包。还要确认 PostgreSQL 的安装路径。默认在C:\Program Files\PostgreSQL\14但很多人装的时候改过盘符。用下面这条命令定位# Windows 下查 PostgreSQL 服务对应的可执行文件路径 sc qc postgresql-x64-14看BINARY_PATH_NAME那一行就能反推出安装根目录。这个路径后面解压覆盖时要用记下来。2.2 bundle 包里到底装了什么为什么不用单独装依赖bundle这个词很关键。PostGIS 依赖一堆第三方库GEOS几何运算、PROJ坐标投影转换、GDAL栅格和矢量格式读写、JSON-C、LibXML2 等。非 bundle 的版本要求你自己把这些依赖一个个装好、配好 PATH在 Windows 上极其折腾这也是「postgis安装失败」的高频原因之一。bundle 包把这些依赖的 DLL 全部打包在压缩包里解压后一起放进 PostgreSQL 的lib和bin目录。所以用 bundle 包时你不需要单独去下 GEOS 或 PROJ也不用手动配环境变量——前提是你解压的时候把文件放对位置。解压前先看一眼压缩包结构。用 7-Zip 或系统自带解压都行但注意别用那种会改文件权限的「压缩大师」类工具之前有同事用某国产压缩软件解压后 DLL 全被加了只读属性覆盖时报错排查半天。解压后目录大致是这样目录/文件作用目标位置lib\*.dllPostGIS 核心库和依赖库PG安装目录\libbin\*.dll运行时依赖PG安装目录\binshare\extension\*.sql扩展定义脚本PG安装目录\share\extensionshare\extension\*.control扩展元信息PG安装目录\share\extension提示解压前先确认压缩包完整。如果解压中途报「missing zip entry」或 CRC 错误说明包损坏重新获取别硬解。3. 解压部署到 PostgreSQL 14把文件放对位置3.1 停服务、备份、再覆盖的三步顺序覆盖文件前必须停掉 PostgreSQL 服务否则正在被占用的 DLL 无法替换会报「文件正在使用」。顺序不能乱# 1. 停止 PostgreSQL 14 服务服务名按实际查到的填 net stop postgresql-x64-14 # 2. 备份原有的 lib 和 share\extension 目录留后悔药 # 假设安装目录是 C:\Program Files\PostgreSQL\14 xcopy C:\Program Files\PostgreSQL\14\lib C:\pg14_lib_backup\ /E /I xcopy C:\Program Files\PostgreSQL\14\share\extension C:\pg14_ext_backup\ /E /I备份这一步别省。我见过有人覆盖完发现版本不对想回退结果原文件没留只能重装整个 PostgreSQL。备份完再解压覆盖# 3. 把解压出来的内容覆盖到安装目录 # 假设解压到了 D:\postgis-bundle xcopy D:\postgis-bundle\lib\* C:\Program Files\PostgreSQL\14\lib\ /E /Y xcopy D:\postgis-bundle\bin\* C:\Program Files\PostgreSQL\14\bin\ /E /Y xcopy D:\postgis-bundle\share\extension\* C:\Program Files\PostgreSQL\14\share\extension\ /E /Y/E表示连子目录一起复制/Y表示覆盖时不询问。覆盖完成后重新启动服务net start postgresql-x64-14如果启动失败第一时间去看 PostgreSQL 的日志位置在PG安装目录\data\log下最新的那个文件。日志里会明确写是哪个 DLL 加载失败比瞎猜快得多。3.2 用 CREATE EXTENSION 激活而不是以为覆盖完就完事文件覆盖只是把「能力」放进去了数据库层面还没启用。PostGIS 是按数据库维度启用的你要在哪个库里用空间功能就在哪个库里执行扩展创建。连上目标库-- 在目标数据库中启用 PostGIS CREATE EXTENSION postgis; -- 如果需要栅格功能再启用这个 CREATE EXTENSION postgis_raster; -- 需要拓扑功能的话 CREATE EXTENSION postgis_topology;执行完不报错说明扩展加载成功。这里有个常见误区有人覆盖完文件就直接去建带 geometry 字段的表结果报「type geometry does not exist」就是因为没执行CREATE EXTENSION。扩展是按库隔离的A 库启用了B 库还得再执行一次。注意CREATE EXTENSION需要超级用户权限普通业务账号执行会报权限不足。用 postgres 超级用户来建。3.3 验证安装三条 SQL 确认版本和功能装完别急着用先跑验证。第一条查 PostGIS 版本SELECT PostGIS_Full_Version();正常会返回一大串包含POSTGIS3.5.0、GEOS3.x.x、PROJx.x.x等信息。如果这里报函数不存在说明扩展没建成功回到上一步检查。第二条做个实际的几何运算确认 GEOS 库能正常工作-- 计算两个点的距离验证几何运算链路 SELECT ST_Distance( ST_GeomFromText(POINT(0 0), 4326), ST_GeomFromText(POINT(3 4), 4326) );预期返回 5。如果返回错误或者结果离谱多半是依赖库版本不匹配。第三条验证坐标投影确认 PROJ 库正常-- 把 WGS84 经纬度转成 Web 墨卡托坐标 SELECT ST_AsText( ST_Transform(ST_GeomFromText(POINT(116.4 39.9), 4326), 3857) );能返回一组墨卡托坐标就说明投影转换链路通了。这三条都过PostGIS 才算真正可用。4. 避坑与排查postgis安装失败最常见的五个原因4.1 现象CREATE EXTENSION 报 could not load library原因基本是 DLL 没放全或者放错目录。bundle 包里的 DLL 分两部分一部分进lib一部分进bin漏了任何一个都会加载失败。还有一种情况是杀毒软件在覆盖过程中拦截了某个 DLL导致文件不完整。解决对照压缩包目录结构重新确认lib和bin都覆盖到位。临时关掉杀毒软件的实时防护再覆盖一次覆盖完再打开。然后用SELECT PostGIS_Full_Version();复验。4.2 现象服务起不来日志报某个 DLL 找不到原因是 PostgreSQL 的bin目录不在系统 PATH 里或者依赖 DLL 被放到了lib而不是bin。Windows 加载 DLL 时先找可执行文件同目录再找 PATH。解决确认所有运行时依赖 DLL 都在PG安装目录\bin下。如果还是不行把PG安装目录\bin临时加到系统 PATH 最前面重启服务测试。确认能起来后再决定是否长期保留这个 PATH 配置。4.3 现象版本号对但装完查询报编码或排序规则错误原因是数据库的 encoding 或 collation 和 PostGIS 预期不符常见于从别处恢复过来的库。PostGIS 对 UTF8 编码支持最好。解决用SELECT datname, pg_encoding_to_char(encoding), datcollate FROM pg_database;查目标库的编码。如果不是 UTF8建议新建一个 UTF8 编码的库来启用 PostGIS别在旧库上硬改编码风险高。4.4 现象解压时报 missing zip entry 或 CRC 校验失败原因是压缩包下载不完整或传输损坏。热词里出现的「missing zip entry」多半就是这个。解决重新获取压缩包下载后先比对文件大小是否和来源标注一致。用 7-Zip 的「测试压缩包」功能先验证完整性再解压。别用来源不明的包二进制文件被篡改的风险很实在。4.5 现象装完能用但一段时间后突然报错原因是系统自动更新或别的软件替换了bin目录下的某个公共 DLL比如某些运行时会往系统目录塞同名库造成版本冲突。解决把 PostGIS 依赖的关键 DLL 在bin目录里留一份备份出问题时对比文件版本。更稳妥的做法是给 PostgreSQL 单独建一个干净的运行环境别和其他会改系统库的软件混装。5. 进阶把 PostGIS 用起来和长期维护的几个习惯装好只是起点真正决定这套环境稳不稳的是后续习惯。第一个习惯是版本锁定把postgis-bundle-pg14-3.5.0x64.zip和对应的 PostgreSQL 安装包一起归档记录下PostGIS_Full_Version()的完整输出。以后任何一台机器复现照着这个输出对齐能省掉大量「为什么这台行那台不行」的排查。第二个习惯是升级前先在小库演练。PostGIS 升级不是覆盖文件那么简单涉及扩展的ALTER EXTENSION postgis UPDATE。正确顺序是先备份数据库在测试库上覆盖新版本文件、执行升级 SQL、跑一遍空间查询验证确认无误再动生产库。升级 SQL 类似-- 覆盖新版本文件并重启服务后在库里执行 ALTER EXTENSION postgis UPDATE TO 3.5.0; SELECT PostGIS_Full_Version();第三个习惯是给空间数据建索引时别偷懒。PostGIS 的查询性能极度依赖 GiST 索引建表后记得加-- 给几何字段建空间索引这是空间查询提速的关键 CREATE INDEX idx_geom ON your_table USING GIST (geom);没有这个索引几万行以上的空间查询就会慢到让你怀疑人生。我一般建完表第一件事就是补索引而不是等慢了再回头加。最后一个习惯是定期用VACUUM ANALYZE维护空间表。空间数据的统计信息对查询计划影响很大尤其是频繁增删几何数据的表。我踩过的坑是一张几十万行的空间表查询突然从毫秒级掉到十几秒排查半天发现是统计信息过期跑一次VACUUM ANALYZE就恢复了。这种问题没有报错纯靠经验所以养成定期维护的习惯比出事再救火划算得多。希望帮到你。本文还有配套的精品资源点击获取