Redis实战：秒杀业务高并发库存扣减与一致性优化
2026/10/27 21:28:44
简介：这份资源是作者在 Windows 下用 msys2 + mingw64 方式预先编译好的 GDAL 1.11.5 库，面向使用 Qt（MinGW 版）做 C++ 桌面开发、需要处理 GIS 栅格与矢量数据的开发者，省去自行搭建编译环境、处理依赖与链接错误的时间。压缩包共 149 个文件，约 70.71MB，以 63 个 h 头文件、22 个 exe 工具程序、28 个 csv 坐标与投影参数表为主，另含 a 静态库、dll 动态库、gfs、wkt、xsd 等配置与模式文件，覆盖开发头文件、运行库和配套数据。已有 1522 人学习下载。解压后将 bin 目录加入系统环境变量，在 .pro 中配置 GDAL 即可调用；作者还针对程序异常结束的情况给出了排错思路，便于快速定位运行库缺失或路径问题，适合希望跳过编译环节、直接进入功能验证与项目集成的开发者参考。
1. 从一次编译翻车说起：为什么 Mingw64 下装 GDAL 1.11.5 值得单独记一笔
上周帮一个做桌面 GIS 的开发者收拾环境，他要在 Windows 上用 Qt 接 GDAL 读矢量数据，结果gdalinfo一跑就报找不到libgdal-1.dll，换了个 MinGW 版本重新编译，又卡在proj_api.h缺失。这类问题在 GDAL 1.11.5 加 MinGW-w64 的组合里特别常见——版本老、依赖链固定、编译器和 Qt 的 ABI 必须严丝合缝。这套环境适合两类人：一是维护老项目的 C++ 开发者，二是需要在 Qt 里嵌 GDAL 做数据转换的桌面端同学。装不好不会报一个清晰的错，而是编译到一半缺头文件、链接期符号对不上，或者运行时 DLL 加载失败，排查成本很高。下面按我实际走通的顺序，把版本、编译参数、Qt 接入和验证一次讲清。
2. 装前把版本和依赖钉死：MinGW-w64、Qt 与 GDAL 1.11.5 的对应关系
GDAL 1.11.5 是 2015 年前后的版本，它的构建系统还是 autotools 那一套，没有 CMake 的现代支持。这意味着编译器、Qt 和第三方库的版本不能随手拿最新的往上套。我一般先把下面这张对照表写进项目 README，后面谁接手都不至于装错。
2.1 版本对照表与工具链选择
| 组件 | 推荐版本 | 说明 |
|---|---|---|
| MinGW-w64 | GCC 4.9.2 / 5.3.0（posix 线程，seh 异常） | 与 Qt 5.5/5.6 官方 MinGW 包一致，避免 ABI 冲突 |
| Qt | 5.5.1 或 5.6.x（MinGW 版） | 必须和编译器同源，别混用 MSVC 版 Qt |
| GDAL | 1.11.5 源码包 | 用gdal-1.11.5.tar.gz，不要拿 git master |
| PROJ | 4.9.x | GDAL 1.11.5 依赖proj_api.h，PROJ 5 之后接口变了 |
| GEOS | 3.5.x（可选） | 需要空间谓词时再编，非必需 |
这里最容易翻车的是 Qt 和 MinGW 的匹配。Qt 官方给的 MinGW 包自带编译器，路径一般在Qt/Tools/mingw492_32或mingw530_32，直接用它，别去另下一个 MinGW 往 PATH 里塞。两个 MinGW 混用，编译能过，链接 Qt 库时会出现undefined reference to _Unwind_Resume这类玄学错误。
2.2 环境变量与目录规划
我习惯把源码和安装前缀分开，避免污染系统目录：
# 假设工作根目录为 D:/gdal-build export SRC_ROOT=/d/gdal-build/src export PREFIX=/d/gdal-build/install export MINGW=/d/Qt/Tools/mingw492_32 export PATH=$MINGW/bin:$PATH # 验证编译器身份，必须和 Qt 同源 gcc --version g++ --versionPREFIX是后面./configure --prefix的目标，所有头文件、库、DLL 都会装到这里，Qt 工程里只认这一个路径。PATH里把 MinGW 放最前，是为了让configure找到正确的gcc。执行完gcc --version要确认输出里的版本号和 Qt 工具链目录名对得上，对不上就先解决这个，别往下走。
提示：Windows 下用 MSYS2 的 bash 跑 autotools 最省事，但编译产物仍是 MinGW 目标，不要用 MSYS2 自带的
/usr/bin/gcc，那是另一套运行时。
3. 编译 GDAL 1.11.5：configure 参数逐个说清
源码包解压后进目录，先跑一次./configure --help看有哪些开关。GDAL 1.11.5 的选项很多，但真正影响 Qt 接入和体积的就那几个。我的原则是：只开需要的驱动，关掉用不上的，编译时间和 DLL 体积都能降下来。
3.1 configure 命令与参数取舍
cd $SRC_ROOT/gdal-1.11.5 ./configure \ --prefix=$PREFIX \ --host=i686-w64-mingw32 \ --with-threads=yes \ --without-libtool \ --with-proj=$PREFIX \ --with-geos=$PREFIX/bin/geos-config \ --without-python \ --without-curl \ --without-pg \ --without-mysql \ --without-odbc \ --disable-shared \ --enable-static逐条说：--host指定交叉目标，32 位 Qt 就写i686-w64-mingw32，64 位写x86_64-w64-mingw32，写错会导致库位数和 Qt 对不上。--with-proj指向前面装好的 PROJ 前缀，GDAL 靠它找proj_api.h。--without-libtool在 MinGW 下能少一层包装，DLL 导出更干净。--disable-shared --enable-static是我在 Qt 桌面项目里的偏好：静态链 GDAL，运行时少一个 DLL 依赖，代价是最终 exe 变大。如果你要多个程序共用 GDAL，改成--enable-shared更合适。
--without-python一定要加，GDAL 1.11.5 的 Python 绑定在 MinGW 下基本编不过，留着只会让 configure 阶段报错。数据库驱动按需关，桌面读文件场景用不到 PostgreSQL 和 MySQL。
3.2 编译与安装
make -j4 make install-j4按 CPU 核数调，老机器给-j2更稳。编译过程中如果报某个驱动缺头文件，回到 configure 加--without-xxx关掉它，别去补装依赖——1.11.5 的驱动太多，全开不现实。make install完成后检查$PREFIX下是否有include/gdal.h、lib/libgdal.a（或bin/libgdal-1.dll），有就说明主体装好了。
注意：如果 configure 报
checking for proj_api.h... no，先确认$PREFIX/include/proj_api.h存在，再确认--with-proj路径没写错。PROJ 自己也要用同一个 MinGW 编，混编一样会失败。
4. 把 GDAL 接进 Qt 工程：.pro 写法与运行时 DLL 处理
编译装好只是第一步，Qt 工程能不能正确链接、运行时能不能找到 DLL，是另一道坎。我见过太多人编译过了，一跑就弹「无法定位程序输入点」。
4.1 .pro 文件配置
# 假设 GDAL 装在 D:/gdal-build/install GDAL_PREFIX = D:/gdal-build/install INCLUDEPATH += $$GDAL_PREFIX/include LIBS += -L$$GDAL_PREFIX/lib -lgdal # 静态链接时还需要这些系统库 win32: LIBS += -lws2_32 -lole32 -luuid -lcomdlg32INCLUDEPATH指向gdal.h所在目录，LIBS里的-lgdal对应libgdal.a或libgdal.dll.a。静态链接时，GDAL 内部用到了 Windows 的 socket、COM 和 UUID 接口，必须补上-lws2_32 -lole32 -luuid，否则链接期会报一堆undefined reference。这几个库的顺序也有讲究，放在-lgdal后面，链接器从左到右解析符号。
4.2 运行时 DLL 与插件目录
如果用的是动态库，libgdal-1.dll必须和 exe 同目录，或者放进 PATH。GDAL 还有一套驱动插件机制，GDAL_DRIVER_PATH环境变量指向$PREFIX/lib/gdalplugins，不设的话部分格式读不了。我一般在main()开头加一句：
qputenv("GDAL_DRIVER_PATH", "D:/gdal-build/install/lib/gdalplugins"); GDALAllRegister();GDALAllRegister()是必须调的，不调的话GDALOpen返回空，很多人以为是路径问题，其实是忘了注册驱动。qputenv在 Qt 里设置环境变量，比改系统环境变量干净，换机器只改一处。
5. 避坑记录：MinGW 编 GDAL 1.11.5 最常见的五个坑
5.1 现象：configure 报proj_api.h找不到
原因：PROJ 没装或装到了别的编译器前缀下。解决：用同一个 MinGW 先编 PROJ 4.9.x，./configure --prefix=$PREFIX后make install，再回来编 GDAL。别用预编译的 PROJ 包，位数和运行时经常对不上。
5.2 现象：链接期大量undefined reference to _imp__...
原因：动态库和静态库混用，或者-lgdal找到了错误的.dll.a。解决：清掉$PREFIX/lib下多余的libgdal.dll.a，只留libgdal.a；确认.pro里没有同时出现-lgdal和手动指定的 DLL。
5.3 现象：程序启动弹「找不到 libgdal-1.dll」
原因：动态链接但 DLL 不在搜索路径。解决：把$PREFIX/bin/libgdal-1.dll拷到 exe 同目录，或用windeployqt之后手动补。静态链接可以彻底绕开这个问题，代价是 exe 体积。
5.4 现象：GDALOpen返回 NULL，文件明明存在
原因：忘了GDALAllRegister()，或GDAL_DRIVER_PATH没设导致插件驱动没加载。解决：在main()里先注册再打开，路径用绝对路径，别用相对路径试。
5.5 现象：编译到某个驱动时报缺sqlite3.h之类
原因：configure 自动探测到了系统里的半套依赖。解决：回到 configure 加--without-sqlite3（或对应驱动开关）重跑，不要临时去补装库，1.11.5 的依赖树补不干净。
6. 装完怎么验证：三步确认这套 GDAL 真的能用
验证不能只看「编译通过」，要分三层：命令行工具、库链接、Qt 运行时。我一般按下面顺序走一遍，任何一步不过就回到对应章节。
第一步，命令行验证。$PREFIX/bin下应该有gdalinfo.exe，跑：
$PREFIX/bin/gdalinfo --version # 期望输出：GDAL 1.11.5, released 2016/04/30版本号对得上，说明主体库和驱动注册没问题。再拿一个小的 shapefile 或 GeoTIFF 跑gdalinfo 文件名，能打出图层信息就说明数据驱动正常。
第二步，链接验证。写一个最小 Qt 控制台工程，只调GDALVersionInfo("RELEASE_NAME")并打印，.pro按第 4 章配置。能编译、能运行、输出1.11.5，说明头文件路径和库路径都对。
第三步，运行时验证。在 Qt 里打开一个真实数据源：
GDALAllRegister(); GDALDataset* ds = (GDALDataset*)GDALOpen("D:/data/test.shp", GA_ReadOnly); if (ds) { qDebug() << "layers:" << ds->GetLayerCount(); GDALClose(ds); } else { qDebug() << "open failed:" << CPLGetLastErrorMsg(); }CPLGetLastErrorMsg()是关键，打开失败时它会给出具体原因，比盲猜强得多。三步都过，这套环境才算真正跑通。
从那以后我每次配 GDAL 加 Qt 的环境，都强制先跑一遍gdalinfo --version再动工程文件，版本不对就停手，绝不带着半套环境往下写代码。希望帮到你。
本文还有配套的精品资源，点击获取