企业官网建设流程全解析

简介：针对Python 2.7环境下在Win7 64位平台安装GDAL的实战指南，面向需要处理地理空间数据的Python开发者、GIS初学者。资源为一份docx文档，共1个文件，包体仅95KB，内容精炼。已有628人浏览学习。文档完整记录两种安装路径：利用core代码配合SWIG自行编译，以及直接下载官方MSI安装，并详细列出过程中常见的错误及解决办法，如swig.exe缺失需安装swig2.10.0并配置环境变量，以及ImportError DLL load failed时需将GDAL的bin目录加入Path。此外还介绍了Visual Studio 2010与GEOS 3.3.8等依赖项的准备工作，帮助读者理清安装顺序与依赖关系。适合在旧版Python环境搭建GIS开发环境时作为参考。

1. 一个老组合的安装困境：Python 2.7 的 GDAL 在 Win7 64 位机上为什么总装不上

GDAL 在 Win7 64 位平台上的 Python 2.7 安装，几乎是每个做遥感、GIS 数据处理的开发者都绕不开的一道坎。这套组合放在今天看确实老旧，但很多存量项目、教学代码和内部工具还跑在 Python 2.7 上，而 GDAL 恰恰是读取栅格、矢量数据最常用的库。装不好会怎样？最常见的就是你在 Python 里敲import gdal，迎面一句ImportError: DLL load failed: 找不到指定的模块，毫无头绪，卡上半天。这篇文章记录的是一套真实踩过坑、最终跑通的完整安装流程，覆盖两个方案——官方 MSI 直装和源码 swig 自编译，以及对应的版本选择思路和三个高频报错的排查方法。适合正卡在 GDAL 安装上的同学照着走，也适合想理解 GDAL 绑定结构、自己动手编译的开发者参考。整个安装过程中每一步参数和路径都写清楚，新手能一步步走通，熟手也能看到版本差异和取舍逻辑。

2. 装前准备：环境依赖与两条安装路线的取舍

2.1 依赖清单：VS2010、GEOS 3.3.8、Python 2.7 缺一不可

GDAL 不是一个单纯 pip 能解决的问题，它底层依赖 C++ 编译产物和一堆动态链接库。在 Win7 64 位平台上装 Python 2.7 版 GDAL，需要先明确环境里有哪些东西、各自起什么作用。下面列一份我最终跑通时的完整环境清单：

这里有个容易被忽略的点：GDAL 的 MSI 安装包和源码包是两套东西。官方提供的 MSI 是预编译好的二进制，装上就能用；源码包里带的是 swig/python 目录，需要自己执行 nmake 编译生成 Python 扩展。两者不是替代关系，而是两种完全不同的安装路径，下文分别展开。GEOS 3.3.8 作为几何库，主要服务于 GDAL 处理矢量几何时的方法调用；只做栅格读写的场景不一定触发，但既然整体环境要求里有它，建议还是按清单装齐，避免后续某个功能调不到库。

2.2 版本选择：为什么最后选了 GDAL 1.9.2 而不是 1.11.0

GDAL 官方对 Windows 平台的老版本支持向来不算友好，尤其是 Python 2.7 这个年代久远的版本，新版本绑定代码对旧编译器兼容性差，报错信息也往往不够直观。我在实际安装时先试了当时最新的 GDAL 1.11.0，理论上同样可以用，但重新配置过程中发现一个问题：网上关于 1.11.0 的资料明显比 1.9.2 少，遇到报错能查到的解决方案也少。最后我退回 1.9.2，纯粹是因为这个版本在 Win7 + Python 2.7 的场景下被踩过太多回，几乎所有错误都能搜到现成答案。

给一个可复用的版本选择逻辑：先看 Python 版本，2.7 就优先选 1.9.x；如果 Python 版本更接近 3.x，那 GDAL 版本要相应上调，但 Python 2.7 配太新的 GDAL 很可能出现 swig 生成的绑定代码语法不兼容的问题。其次是看编译器，VS2010 意味着 nmake 的版本是 10.00.30319.01，这个环境下 GDAL 1.9.2 的 makefile 是验证过能走的；换 VS2008 或 VS2012 都可能需要额外调整环境变量。最后才是功能需求，GDAL 1.9.2 对绝大多数栅格格式和矢量格式的支持已经足够用，没必要为了用新格式去冒安装风险。

2.3 两条路线的取舍：官方 MSI 直装和 swig 自编译哪个适合你

官方给出了两种可选方案：一是利用 core 代码自带的 swig/python 自己编译，二是下载官方提供的 MSI 文件直接点击安装。两条路线我都完整实验过，都成功，但适合的人群完全不同。直接说结论：如果你只是想快速在 Python 里用上 GDAL，不想关心底层编译细节，选 MSI 方案；如果你想搞清楚 GDAL 的 Python 绑定是怎么生成的，或者想改绑定代码，选源码自编译方案。在实际工程中，两种方案会直接影响后续的排错路径：MSI 方案下 DLL 加载失败只需要查环境变量；源码方案下失败还可能是 swig 版本问题、编译器版本问题、甚至 makefile 里的路径问题。

中间如果拿不定主意，我的建议是先走 MSI 方案把环境跑通，再回头去折腾源码编译。这个顺序能帮你把一个变量（环境配置）和一个变量（编译过程）分开排查，否则一旦出问题，不知道是该怀疑 Path 配置还是该怀疑编译产物，排查成本直接翻倍。这算是这次安装过程中最值得记住的一条经验。

3. 路线一：官方 MSI 直装 GDAL，两步解决 DLL 环境

3.1 下载与安装：MSI 包版本必须对应 Python 2.7 的 64 位环境

MSI 方案的思路很简单：下载官方提供的 GDAL 安装包，按引导安装完成，再把安装目录下的 bin 文件夹加入系统 Path。高效的前提是版本选对，MSI 文件名里通常会标注版本号和平台信息。以 1.9.2 为例，安装包名称中应包含 x64 字样，对应 64 位系统；如果误装成 32 位版本，随后在 64 位 Python 2.7 里 import gdal 时同样会报 DLL 加载失败，而且报错信息几乎和路径问题一模一样，非常容易混淆。这是一个很容易被忽视的点，安装时多看一眼文件名，能省掉后面一两个小时。

安装过程本身很简单：以管理员身份运行 MSI，安装路径建议保持默认。对 1.9.2 来说，默认安装目录为C:\Program Files\GDAL192。为什么不建议自定义路径？因为后续所有教程和资料里的路径都以默认目录为例，你一旦改了，查资料时就要自己在心里换算一遍，出错概率更大。GDAL 的 MSI 安装过程没有太多交互，一路下一步即可，装完先不要急着启动 Python，先把环境变量配好，否则必然会在 import 阶段撞上 DLL 问题。顺带说一句，安装 MSI 之前确认 VS2010 和 GEOS 3.3.8 都已装好，虽然 MSI 方案不依赖 VS2010，但 GEOS 的 DLL 会被 GDAL 运行时调用，缺少时会触发另一个 Dll load 失败。

3.2 配置环境变量：把 GDAL 的 bin 目录写进系统 Path

这一步是整个 MSI 方案里最关键的配置项。强行忽略它也可以正常安装，但跑到import gdal时就会触发当场翻车。操作路径是：右键“计算机”，选择“属性”，点击“高级系统设置”，在“高级”选项卡里点击“环境变量”，在“系统变量”区域找到名为Path的变量，点“编辑”，在变量值末尾追加 GDAL 的 bin 目录。具体追加内容根据安装路径来，默认情况下是：

C:\Program Files\GDAL192\bin

也可以用命令行的方式追加。由于是在 Win7 上手动配置，打开 cmd 直接执行下面的 setx，效果等同：

setx Path "%Path%;C:\Program Files\GDAL192\bin"

追加完 Path 后务必重开命令行窗口，因为环境变量是进程启动时读取的，旧窗口里改动的 Path 不会生效。这里需要说明一个细节：为什么是 bin 目录而不其他？因为 GDAL 的 Python 绑定模块在导入时，需要通过动态链接方式找到gdal192.dll，而 Windows 默认不会在当前目录或 Python 的 site-packages 目录下寻找 DLL，只能靠系统 Path 中的目录。一旦找不到，就会出现“找不到指定的模块”。把 bin 加进 Path，就是告诉系统去哪里找gdal192.dll和其他相关 DLL，这是 GDAL 安装中最基本也最容易被忽视的一步。

3.3 验证导入：from osgeo import gdal 一条命令判断成败

环境变量配置完成后，重新打开一个命令行窗口，进入 Python 交互环境执行验证：

from osgeo import gdal print(gdal.VersionInfo())

如果输出类似1910这样的版本号，说明 GDAL 已经可以正常导入。需要注意，旧版本 GDAL 的 Python 绑定同时支持import gdal和from osgeo import gdal两种写法，但推荐统一用from osgeo import gdal，因为后续版本已经逐步废弃顶层import gdal的方式。MSI 方案到这里就结束了，总耗时不超过 10 分钟。不过看 gdalinfo 源码时能注意到，GDAL core 的读取流程是：打开数据源、获取驱动、读取栅格波段。如果你在后续使用中遇到“driver 未注册”或“无法识别格式”的问题，多半是 GDAL_DATA 环境变量没有配置或配置错误，这个不在本节范围内，留在验证一章里展开。MSI 方案能以最少步骤跑通，路径配置是唯一的坎，跨过去就顺了。

4. 路线二：源码自编译 swig/python，动手构建 Python 绑定

4.1 用 X64 兼容命令提示符构建 GDAL core：先给自己一个干净的编译环境

源码方案的第一步，是拿到一个正确的编译环境。GDAL 1.9.2 的源码包默认通过 nmake 构建，而 nmake 不是一个独立可执行文件，它依赖 Visual Studio 提供的一系列环境变量和工具链。直接打开普通的 cmd 窗口执行 nmake 会得到“不是内部或外部命令”的报错。正确做法是：以管理员身份，打开“开始”菜单，依次进入“所有程序”，找到 Microsoft Visual Studio 2010 目录下的 Visual Studio Tools，然后打开“Visual Studio X64 兼容工具命令提示符”。这个工具会自动设置好 64 位编译相关的环境变量，包括 nmake 的路径。注意这里一定要选 X64 兼容命令提示符，而不是普通的命令提示符，否则后续编译出来的 DLL 可能是 32 位的，与 64 位 Python 2.7 不匹配，最终还是会卡在 DLL 加载。

打开正确的命令提示符后，切到 GDAL 源码解压目录下的 swig 目录。以我的环境为例，源码解压在C:\OGC\GDAL192\gdal-1.9.2，所以执行：

cd C:\OGC\GDAL192\gdal-1.9.2\swig

4.2 执行 nmake 生成 Python 绑定：会遇到不太常见的一个问题

进入 swig 目录后执行编译命令，准备让 nmake 根据 makefile.vc 生成 Python 绑定代码：

nmake /f makefile.vc python

这条命令的作用是调用 makefile.vc 中的 python 目标，它会先去检测 swig.exe 是否存在，然后执行 swig 命令生成gdalconst_wrap.c、gdal_wrap.c等绑定代码，最后调用编译器把它们编译成_gdal.pyd。在这个场景下，第一次执行大概率会在中间出现'swig.exe' 不是内部或外部命令的报错，并伴随 nmake 的fatal error U1077退出。出现这个现象的原因很简单：系统环境里没有安装 SWIG 工具。解决方式是下载 SWIG 2.10.0，解压后将 swig.exe 所在的目录追加到系统 Path 环境变量中，然后重开命令行窗口再次执行上面的 nmake 命令，一般就能顺利通过这一步。SWIG 2.10.0 是兼容这套老环境的一个版本，太新的 SWIG 生成代码可能依赖较新的 Python 特性，反而不适合 Python 2.7。

4.3 安装 Python 扩展时遇到 Vcvarsall.bat 找不到：直接用环境变量绕过

nmake 流程跑完后，当前目录下会生成一个 python 子目录，绑定代码和 setup.py 都在里面。切换到该目录并执行 Python 的构建与安装命令：

cd python python setup.py build python setup.py install

构建到一半时，大概率会出现unable to find Vcvarsall.bat的错误。这个报错的原因是 distutils 在查找 VS2008 的环境配置文件，因为它默认认为 Python 2.7 是用 VS2008 编译的。而当前机器只装了 VS2010，没有 VS2008，所以找不到对应的 Vcvarsall.bat。网络上有建议改用 mingw 编译的，我试验过，在这个老 GDAL + Python 2.7 组合下基本走不通，会遇到格式兼容、缺少头文件等一系列问题。实际能直接绕过这个检查的办法是在命令行窗口手动设置一个环境变量：

set VS90COMNTOOLS=%VS100COMNTOOLS%

这条命令的作用是把 VS2010 的工具集路径临时伪装成 VS2008 的路径，让 distutils 能正常找到编译器。注意这里用的是set而不是setx，意思是只在当前命令行窗口生效，不影响系统全局设置。执行完这条命令后，重新执行：

python setup.py build python setup.py install

这次 build 过程会输出大量编译信息，中间夹杂很多 warning，这是正常的，不需要逐一处理。只要最终能看到Finished processing dependencies或类似字样，说明绑定模块已经被复制到 Python 的 site-packages 目录下，这一步就算过了。这里有个常见的误解：看到屏幕上滚过一篇红色警告就以为失败了，其实真正失败时 nmake 会直接报 U1077 中断，而 build 阶段的多数报警是编译器对旧代码的兼容性提示，不影响最终产物。

4.4 编译完成也不能忽略的收尾配置：bin 目录依然要进 Path

源码编译完成后，不要以为事情就结束了。编译出来的 Python 绑定模块_gdal.pyd只是 GDAL Python 层的壳，真正执行读写操作的是gdal192.dll。此时在命令行里执行python -c "from osgeo import gdal"，大概率仍会碰到那个熟悉的ImportError: DLL load failed: 找不到指定的模块。这不是编译失败了，而是 Python 找不到底层 DLL。解决方式和 MSI 方案完全一致：把 GDAL 编译安装目录下的 bin 目录加入系统 Path。无论哪种安装方式，这一步都省不掉，因为 Windows 的动态链接库搜索机制不认 Python 的 site-packages，它只认系统 Path 里的目录。我把这一步放在最后讲，是想强调一个容易忽略的细节：源码方案虽然过程复杂，但最终产生的问题和 MSI 方案是同一个，排查方向不要跑偏。在配置 Path 时，注意区分 GDAL core 的 bin 目录和 Python 安装目录下的 Scripts 目录，两者职责完全不同，前者管 DLL，后者管可执行脚本，需要分开追加。

5. GDAL 安装避坑：三个高频报错的现场重演

5.1 错误一：'swig.exe' 不是内部或外部命令，也不是可运行的程序

现象：在 swig 目录下执行nmake /f makefile.vc python，终端直接提示 swig.exe 不是内部或外部命令，随后 nmake 报fatal error U1077退出，构建中止。

原因：SWIG 工具根本没有安装，或者安装了但没把可执行文件所在目录加入 Path。nmake 在执行 makefile.vc 时，会调用 swig.exe 来解析.i接口文件并生成 C 包装代码，这一步是整个 Python 绑定生成机制的起点，缺失 swig 就等于断了源头。

解决：下载 SWIG 2.10.0，解压后把 swig.exe 所在目录追加到系统 Path，重开命令行窗口，再次执行原命令。注意一定要重开窗口，否则新追加的 Path 不会加载到当前进程。

5.2 错误二：unable to find Vcvarsall.bat

现象：执行python setup.py build时，distutils 抛出unable to find Vcvarsall.bat，构建无法继续。

原因：Python 2.7 的官方安装包是用 VS2008 编译的，因此 distutils 在构建扩展模块时，会优先查找 VS2008 的 Vcvarsall.bat。机器上只装了 VS2010 时，根本没有 VS2008 的路径可查，于是判定为找不到编译器。

解决：在命令行窗口执行set VS90COMNTOOLS=%VS100COMNTOOLS%，把 VS2010 的环境变量伪装成 VS2008。这个方案比换 mingw 靠谱得多，我亲自试过 mingw 路线，折腾半天依旧会出现各种库兼容问题。另外提醒一句，如果你装了 VS2008，这一步可以直接跳过。

5.3 错误三：ImportError: DLL load failed: 找不到指定的模块

现象：MSI 安装完成或源码编译完成，在 Python 中执行import gdal，抛出ImportError: DLL load failed: 找不到指定的模块，堆栈中能看到 osgeo 包的swig_import_helper内部加载失败。

原因：这是整个安装过程中最容易让人心态炸裂的报错，也是最常见的问题。核心原因就是 Python 在导入_gdal.pyd时，需要动态加载gdal192.dll，但这个 DLL 所在的 bin 目录没有在系统 Path 中，所以系统找不到指定模块。小问题纠结老半天，通常就是差这一步。

解决：把 GDAL 安装目录下的 bin 目录追加到系统 Path。MSI 默认路径追加C:\Program Files\GDAL192\bin，源码编译场景则追加你编译产物所在的 bin 目录。追加后重启命令行窗口，再执行from osgeo import gdal。如果依然报同样错误，检查 Python 是否 64 位，以及安装的 GDAL 是否也是 64 位版本，位数不一致也会复现同一个错误。

5.4 容易忽略的连带问题：装了两个 GDAL，命令就不知所踪了

现象：环境里同时存在 MSI 安装的 GDAL 和源码编译的 GDAL，命令行执行 gdalinfo 时报错或版本对不上，Python 里 import 的也可能不是你期待的那份。

原因：MSI 和源码编译各自会把文件复制到不同位置，但都会往 Python 的 site-packages 写入同名包。Path 中前面的目录优先生效，两个版本互相覆盖，导入时拿到哪个完全取决于系统搜索顺序，难排查到。

解决：只保留一条安装路线的产物，删掉另一条。以 ms 为主：先卸载 MSI 版，再把源码编译版的相关目录从 Path 和环境变量中清理干净。如果不确定哪些文件残留，可以在 Python 里查看实际加载路径，一般写在osgeo包的__file__属性里。切记不要两个版本共存，后续调试时完全分不清来源。

6. 装完怎么验证跑通：用 gdalinfo 和一段小脚本确认环境可用

6.1 命令行三件套：快速确认 DLL 与版本状态

不依赖任何 IDE，直接开一个 cmd，依次执行三条命令确认基础环境健康。

python -c "from osgeo import gdal; print(gdal.VersionInfo())"

输出1910之类的版本号，说明 Python 已能加载 GDAL。第二步：

gdalinfo --version

这个命令确保命令行工具本身就绪，且能拿到同一个版本的 GDAL 二进制。第三步：

python -c "from osgeo.gdalconst import *; print('ok')"

确认 gdalconst 模块的绑定也是通的。这三条命令覆盖了 GDAL Python 绑定的完整调用链：Python 找到绑定模块、绑定模块找到 DLL、命令行工具找到同一套二进制。三条都通过，环境基本没有问题了。如果第一条过而第二条报错，问题大概率出在系统 Path 里 GDAL 的 bin 目录没有配好；如果第一条报错而第二条正常，问题出在 Python 环境本身，比如 32 位 Python 装了 64 位 GDAL。

6.2 用 gdalinfo 读一张实际的栅格图：最简单的落地验证

环境变量验证通过，只说明“库能加载”，还不能说明“数据能读”。用 gdalinfo 读取一张真实的栅格文件，才算跑通完整调用链路。

gdalinfo E:\test_data\landsat8\LC08_L1TP_001001_20180601_B1.TIF

输出中重点看几个信息：Driver是否正常识别为 GTiff，Size是否匹配图像真实尺寸，Band 1下方的Type和NoData Value是否符合预期。如果报错Unable to open，优先检查文件路径和文件名是否有中文；GDAL 老版本在 Windows 上对中文路径支持并不稳定，实际使用中建议把测试数据放到纯英文路径下，比如E:\test_data\，避开中文目录是最省事的习惯。这个验证方式比单纯 import 更接近实际业务场景，数据能成功打开，说明从 Python 绑定到底层驱动再到文件格式解析，整条链路都是通的。

6.3 留一个习惯：每次换机器装机都强制走一遍三件套

从那次安装之后，我养成了一个习惯：任何一台新机器装完 GDAL，不管用的是 MSI 还是源码编译，第一时间跑上面三件套，而不是直接打开业务脚本。这个习惯帮我挡掉了不少换机后的低级问题。有一次在另一台 Win7 上，import 正常，但 gdalinfo 怎么都调不到版本，最后检查出来是系统 Path 里同时存在两个版本的 bin，新旧 DLL 互相干扰，清理后才恢复。有了这套验证方法，开发时至少能确定“环境没问题的前提”是成立的，剩下排错就能放心地去找代码本身的毛病。

这个组合的安装本身不难，难的是版本选错、路径没配、位数不匹配这些细枝末节的纠缠。希望这份笔记能帮你少走一些弯路，一次把 GDAL 在 Python 2.7 的 Win7 环境里装通。

本文还有配套的精品资源，点击获取