企业官网建设流程全解析

1. 为什么都2025年了，我还要写一份ArcGIS 10.2.2的Python配置教程

前两天在群里看到有人问"ArcGIS 10.2.2自带的Python 2.7.5怎么装pip"，底下还有人回复"用Python 3不好吗？"。说实在的，这个版本确实老了点，但架不住还有大量单位、科研项目、老库房里的数据管线在用这套软件。有很多机器承载着历史项目，不能随便升级，一旦动版本，几个老脚本、自定义工具箱全得跟着改，风险太大。所以折腾好自带的Python 2.7.5环境，依然是某些场景下的刚需。

这篇博文不聊要不要换平台，只聊怎么把ArcGIS 10.2.2自带的Python 2.7.5环境收拾利索——从最让人头疼的pip安装，到国内源配置，再到gdal库的二进制安装和arcpy模块的正常调用。每一步我都自己踩过坑，文中会把这些坑的位置、原因、绕行方案都讲清楚。只要你手里有ArcGIS 10.2.2安装包，照着一步步操作，半小时内就能把这套老环境调到能正常pip装包、能import arcpy、能跑gdal脚本的状态。

适合三类人看：第一类是GIS方向的在校生，实验室或老师给的课程资料依赖10.2.2；第二类是自然资源、测绘、规划相关单位的技术人员，内网机器锁定版本不能动；第三类是接手老项目的开发维护者，需要在不破坏现有环境的前提下补齐Python工具链。至于那些可以自主选型的新项目，我建议直接上ArcGIS Pro或Python 3，没必要在这里受罪。

说句实在话，ArcGIS 10.2.2的Python 2.7.5环境本质上是一个"锁了门的完整Python"，ESRI在安装时已经装好了numpy、matplotlib这些常用包，但没有顺手装pip。这种半封闭状态导致很多人第一次想装第三方库时就卡住了。接下来每一步我都会配合实际操作说明，尽量让你少走弯路。

2. 动手前先摸清环境：路径、位数、还有那个极易被忽视的Desktop10.2文件夹

很多教程上来就让你跑命令，结果跑到一半发现路径不对、装错了位数，甚至根本不知道自己的Python被装到了哪里。ArcGIS的Python环境跟普通Python安装不太一样，路径结构有它自己的脾气，先花三分钟把基本盘摸清，后面能省下一大堆事。

2.1 找到真正的Python解释器

ArcGIS 10.2.2安装时，Python 2.7.5会被安装到ArcGIS安装目录下的Python27文件夹里，典型路径是：

C:\Python27\ArcGIS10.2\

注意，不是C:\Python27\根目录，也不是C:\ArcGIS\Python27\。这一点特别容易看错。ESRI把解释器放在C:\Python27\ArcGIS10.2\python.exe，除此之外可能还有C:\Windows\py.exe之类的其他存在，但ArcGIS实际调用的就是上面这个。

验证方法很简单，打开命令行，切换到该目录，执行：

C:\Python27\ArcGIS10.2\python.exe -c "import sys; print(sys.version)"

如果输出了2.7.5 (default, May 15 2013, 22:44:16) [MSC v.1500 32 bit (Intel)]，说明路径正确。注意看32 bit字样。

2.2 32位还是64位，装错就是白折腾

ArcGIS 10.2.2的Desktop版本默认随附的是32位Python 2.7.5，虽然你的操作系统大概率是64位Windows，但解释器本身是32位的。这就带来一个连锁反应：后续安装任何第三方库，版本都必须对应32位（win32）的wheel包，你要是装了64位的GDAL、PyQT或者其他编译包，就会出现各种DLL load failed或者ImportError: No module named的玄学问题。

这可能是整套配置里最核心的一个认知。很多人卡在gdal导入阶段很多天，最后发现只是把64位的包装进了32位解释器。

怎么确认当前位数？在上一步的sys.version输出里已经写了32 bit，也可以在Python里执行：

import struct print(struct.calcsize("P") * 8)

输出32就是32位解释器，64就是64位。

2.3 检查环境变量与“默认真实解释器”的问题

ArcGIS 10.2.2的安装程序通常不会把Python目录加到系统PATH里，这就是为什么你在命令行直接敲python --version经常会提示"不是内部或外部命令"。这倒不是大问题，后面配置pip时会解决，但你自己得清楚：得用绝对路径调用，或者把目录手动加到PATH里。

另外，如果你机器上同时装有其他Python版本（比如Python 3.9或者Anaconda），命令行里的python指向的很可能不是ArcGIS这个，装包时极易装错地方。为解决这个问题，建议配置完成后，单独把C:\Python27\ArcGIS10.2和C:\Python27\ArcGIS10.2\Scripts加入PATH，并且排在系统PATH的前面，保证执行的python和pip都指向ArcGIS的环境。

注意：修改PATH前先记录原值，方便今后恢复。改完后新开的命令行窗口才会生效。

概括一下：这阶段的目标不是立刻装包，而是彻底搞清楚你手里的解释器在哪、是什么位数、默认会不会跑错。这三件事不确认明白，后面的pip、gdal、arcpy全都会出一些让人抓狂的疑难杂症。

3. pip安装全流程：用get-pip.py绕过最经典的“无pip”困境

ArcGIS 10.2.2自带的Python 2.7.5，安装目录下没有pip。如果你直接运行pip -V，系统会无情地告诉你"pip不是内部或外部命令"。这在当年是个老生常谈的问题，解决办法也比较统一：用get-pip.py引导安装。

3.1 下载与执行get-pip.py

需要先下载适合Python 2.7的get-pip.py脚本，因为Python 2.7已经停止维护，新版get-pip.py往往只支持Python 3，所以找历史版本或者从pip官方仓库的2.7分支拿比较稳妥。

下载完成后，把脚本放到一个方便的位置，比如C:\Python27\get-pip.py，然后执行：

C:\Python27\ArcGIS10.2\python.exe C:\Python27\get-pip.py

正常情况下，脚本会自动安装pip、setuptools和wheel。安装完成后，检查一下是否成功：

C:\Python27\ArcGIS10.2\python.exe -m pip --version

如果输出pip 9.0.1 from C:\Python27\ArcGIS10.2\lib\site-packages (python 2.7)，说明装好了。为什么特别提"pip 9.0.1"？因为它基本是Python 2.7能用的最后一个稳定大版本，后面的pip 18、19虽然也支持2.7，但有些依赖会出问题。用get-pip.py在2.7下安装时，拿到的一般就是9.x版本，这也是符合实际预期的一个结果。

3.2 Scripts目录与命令找不到的问题

pip安装后会生成C:\Python27\ArcGIS10.2\Scripts\pip.exe。但命令行直接敲pip时可能会提示找不到命令，原因很简单——Scripts目录不在PATH里。解决办法有三个：

1. 把C:\Python27\ArcGIS10.2\Scripts加入系统PATH；
2. 每次使用C:\Python27\ArcGIS10.2\python.exe -m pip替代直接敲pip；
3. 用C:\Python27\ArcGIS10.2\Scripts\pip.exe绝对路径调用。

我个人的建议是把Scripts目录加进PATH，因为后面很多命令行工具（比如gdal的几个脚本工具）也会安装到这个目录，不用绝对路径的话太痛苦。但如果你极其排斥改PATH，那么python -m pip这种写法是第二优选。

3.3 配置国内镜像源，源不好等于装什么都慢

如果你是裸网络环境，用官方源装一个小包装半天都是常事，甚至直接超时失败。配置国内源是最实际的一步优化。Python 2.7里的pip不支持较新的pip config命令部分功能，但可以通过修改配置文件实现。Windows下路径为：

C:\Users\你的用户名\pip\pip.ini

如果pip文件夹和pip.ini文件都不存在，就手动创建。内容如下：

[global] index-url = https://pypi.tuna.tsinghua.edu.cn/simple [install] trusted-host = pypi.tuna.tsinghua.edu.cn

第一行指定了包下载源，第二行是为了让pip信任该源的HTTPS证书，避免在不受信任的情况下被拒绝。如果清华源速度不理想，可以换成阿里云源：

index-url = https://mirrors.aliyun.com/pypi/simple/ trusted-host = mirrors.aliyun.com

我个人习惯是清华源优先，必要时换阿里。配置好后，用pip install numpy这类命令实测一下下载速度，应该能明显感觉到差别。

3.4 验证pip可用性的三个命令

配置完成后，建议依次执行以下三个命令，确认pip真的可用：

C:\Python27\ArcGIS10.2\python.exe -m pip --version C:\Python27\ArcGIS10.2\python.exe -m pip list C:\Python27\ArcGIS10.2\python.exe -m pip install setuptools --upgrade

pip list能看到目前已安装的包列表，ArcGIS预装的numpy、matplotlib、pyparsing等会出现在里面。把setuptools升级一下，是为了避免老版本setuptools在后续安装某些依赖包时出现兼容性错误。

到这里，pip已经不再是拦路虎。类似的安装逻辑其实适用于ArcGIS 10.0、10.1、10.4等老版本，只要底层还是Python 2.7，这套引导流程就大体相同。具体差别主要体现在路径和版本号上，掌握原理后就能一通百通。

4. 为Python 2.7.5安装gdal：版本匹配是唯一王道

很多人装gdal都是从源码编译开始，结果被复杂的依赖关系折磨到怀疑人生。别把自己搞得那么累——在Windows上给老Python装gdal，直接用编译好的wheel包，除非特殊场景，否则别碰源码编译。

4.1 从哪里找适合的gdal wheel

Python 2.7能用的gdal wheel，最常用的来源是Christoph Gohlke维护的非官方二进制包页面。这个网站像一座宝库，上面几乎各种Python版本、各种位数、各种库的Windows安装包，尤其适合老版本Python。虽然网站界面很朴素，但实用价值极高。

你需要找的文件名大致长这样：

GDAL-2.2.4-cp27-cp27m-win32.whl

拆开解释一下：

• cp27表示CPython 2.7；
• cp27m表示启用了Unicode UCS4的构建（Python 2.7默认就是）；
• win32表示32位Windows版本，不是win_amd64。

下载时务必看清这三个标记，三者任一不匹配，装完都会出错。还记得前面解释器是32位这件事吗？这就是决定因素。如果你下载了win_amd64的包，pip会直接报"not a supported wheel on this platform"，或者强迫你使用--force-reinstall，但装完后import gdal时会报DLL错误。

4.2 安装gdal wheel包

拿到whl文件后，通过pip安装即可：

C:\Python27\ArcGIS10.2\python.exe -m pip install C:\Downloads\GDAL-2.2.4-cp27-cp27m-win32.whl

不推荐用pip install gdal直接从源站拉取，因为Python 2.7下很可能找不到匹配的预编译包，然后它会尝试下载源码并编译，没有完整VC++ 9.0编译环境的话，基本是必败结局。

安装完成后gdal会自带一个隐藏依赖——numpy，如果你系统中已经存在ArcGIS自带的numpy，它会复用之前的版本，一般能满足需求。实测中，ArcGIS 10.2.2自带的numpy版本是1.7.1，gdal 2.2.4要求numpy>=1.5.0，完全满足条件。

4.3 验证导入并解决“DLL load failed”问题

安装只是第一步，真正的考验是导入：

C:\Python27\ArcGIS10.2\python.exe -c "from osgeo import gdal; print(gdal.__version__)"

如果输出2.2.4，恭喜你，成功了。如果报ImportError: DLL load failed: The specified module could not be found，大概率原因有三：

1. 装了64位gdal但解释器是32位；
2. 缺少VC++ 9.0运行库；
3. gdal的dll依赖的某些系统文件缺失。

第一个问题的解决办法是卸载重装32位版本；第二个问题的解决办法是安装Microsoft Visual C++ 2008 Redistributable Package（x86）；第三个问题一般会在安装完VC++运行库后自动解决，因为gdal的dll依赖的通常是系统通用运行库。

还有一个容易忽视的问题：ArcGIS自带的Python 2.7.5路径下没有osgeo目录，但gdal装好后会自动生成。如果你在另一套Python环境里也装了gdal，并且两个环境的site-packages路径存在混用，也会出现"版本莫名其妙"的情况。为了避免环境串味，建议用前面提到的绝对路径来执行Python命令，确保始终操作的是正确的那一套环境。

4.4 顺便把gdal的Python脚本也加入路径

gdal wheel包内会附带一些可执行的Python脚本，比如gdalinfo.py、ogr2ogr.py。这些脚本会被安装到C:\Python27\ArcGIS10.2\Scripts\目录下，跟pip.exe在一起。实际使用中，你完全可以在Python代码里调用gdal的API，而不必依赖这些命令行脚本，但如果你有命令行处理栅格、矢量数据的习惯，把它们加入PATH也挺好。

到这里，gdal部分就算全通了。一个常见问题提醒一下：gdal版本新旧会影响API行为，2.2.4还算是一个比较经典的版本，跟ArcGIS 10.2.2搭配时，似乎在重投影、格式转换这些常规操作上都没有发现明显兼容性问题。

提示：不要在ArcGIS自带的Python里试图安装gdal 3.x系列。那类版本主要面向Python 3环境，部分数据结构已经变了，强行装到2.7上虽然不会让你电脑爆掉，但使用新版API时会有很多接口坑，没必要给自己找麻烦。

5. arcpy调用：让脚本在ArcGIS之外也能平稳运行

arcpy和gdal是很多GIS脚本里的两套主力工具。gdal是通用地理数据读写库，arcpy则是ArcGIS的专有Python接口。很多人配置完gdal以为大功告成，结果在命令行里尝试import arcpy时又碰壁了。下面先把arcpy的机制讲清楚，再给出具体调用方法。

5.1 arcpy到底是啥，为什么不能随便import

arcpy是ESRI提供的Python站点包，它不是一个独立的第三方库，而是深度绑定ArcGIS Desktop安装环境的。它依赖很多ArcGIS的底层COM组件、许可管理器以及arcgis安装目录下的一系列dll。你在Python命令行里直接import arcpy，Python解释器需要在site-packages里找到arcpy文件夹，同时还要能在系统里定位到ArcGIS的DLL和License相关服务。

ArcGIS 10.2.2安装时，已经自动把arcpy站点包放进了C:\Python27\ArcGIS10.2\Lib\site-packages。理论上，用正确的解释器去import，是能直接成功的。但很多人实际运行时报ImportError: No module named arcpy，原因一般有两个：一是你用了错误的Python解释器（比如系统的Python 3或另一个Python 2.7），二是当前命令行的工作目录或PYTHONPATH变量出了问题。

5.2 命令行里验证arcpy

打开命令行，执行：

C:\Python27\ArcGIS10.2\python.exe -c "import arcpy; print(arcpy.GetInstallInfo()['Version'])"

如果输出10.2.2，说明arcpy在命令行环境下已经可用了。如果提示RuntimeError: Not initialized或者类似错误，大概率是ArcGIS许可服务没启动，或者你的机器上根本没有有效的ArcGIS许可。这时候需要打开ArcMap或ArcCatalog一次，让软件初始化许可后再试。

有一点值得说明：arcpy在命令行里的行为跟从ArcMap的Python窗口里运行并不完全一样。在ArcMap的Python窗口里，ArcGIS会自动注入一些环境变量和许可相关信息，所以经常出现"窗口里能跑，命令行跑不了"的怪象。知道了这个差异，去排查时就有方向了。

5.3 在脚本里合理混用arcpy和gdal

有些场景下，你可能希望在gdal和arcpy之间快速切换。举个典型例子：用gdal读一个大尺寸GeoTIFF的元数据，再用arcpy做要素类层面的分析。这种混用在老环境里完全可行，只要注意数据格式之间的转换就行。

# -*- coding: utf-8 -*- from osgeo import gdal import arcpy # 用gdal读取栅格尺寸 ds = gdal.Open(r"D:\data\dem.tif") width = ds.RasterXSize height = ds.RasterYSize print(u"栅格尺寸: {0} x {1}".format(width, height)) # 用arcpy创建要素类 arcpy.env.workspace = r"D:\data" fc = "sample.shp" if not arcpy.Exists(fc): arcpy.CreateFeatureclass_management(r"D:\data", "sample.shp", "POLYGON") print("arcpy create done")

这只是一个很小的示例，但你可以从中看出两者配合使用的基本姿势。使用过程中，务必要注意数据路径分隔符的写法。Python 2.7在Windows中文路径下经常踩编码坑，所以脚本文件头最好加上# -*- coding: utf-8 -*-，涉及中文路径时建议在字符串前加u前缀，必要时用decode('gbk')或encode('utf-8')做转换。因为ArcGIS 10.2.2那个年代的Windows中文环境，文件路径的编码完全是GBK体系的，不处理的话，写字楼里没少见"SyntaxError"或者"IOError: [Errno 22] invalid mode"这类质疑。其实根源就是编码问题。

5.4 处理arcpy环境变量与输出路径

用arcpy时，arcpy.env.workspace是全局变量，设置后大多数工具函数都默认在这个工作空间里操作。而gdal则更倾向于用路径字符串直接传参数。混用时，建议每个函数都显式传递完整路径，而不是依赖环境变量，避免两边状态不一致导致找不到文件。

另外，arcpy对输出路径存在"已存在"判断逻辑，如果目标文件已经存在，部分工具会报错，所以写脚本时先arcpy.Exists()判断一下是好习惯。这点跟gdal的处理方式很不一样，gdal的CreateCopy会默许覆盖，而arcpy的很多工具如果存在同名的要素类或数据集，会直接拒绝执行。

6. 实战踩坑与排查链路：pip报错、DLL缺失、版本混乱逐个拆解

老环境配置的最大问题有两个：一是可用文档少且分散，二是很多报错信息看起来像英文天书，实际上原因却很简单。把我前后折腾的坑整理成排查链路，一次性说清楚。

6.1 pip调用报错的三种典型场景

场景A：输入pip -V提示"不是内部或外部命令"。原因是Scripts目录未加入PATH，或者安装后新开的命令行窗口没生效。解决：确认C:\Python27\ArcGIS10.2\Scripts在PATH中，关掉命令行重新开。

场景B：输入pip提示Fatal error in launcher: Unable to create process using...。这个问题在Python 2.7的pip里很常见，多数时候是pip的shebang行或者环境变量指向了另一个版本的Python。解决：用C:\Python27\ArcGIS10.2\python.exe -m pip ...代替直接调用pip.exe，或者重新执行一次get-pip.py修复pip。

场景C：安装包时提示Could not find a version that satisfies the requirement。这是Python 2.7的老生常谈，由于大量新库已放弃Python 2.7，版本支持列表里匹配不到新版，并不意味着库不存在。解决：指定可用版本号，比如：

python -m pip install pandas==0.24.2 python -m pip install requests==2.22.0

如果不是非要最新版，尽量选择2.7时代最后一个大版本，稳定性会更有保障。

6.2 gdal导入报错的完整排查链路

一步步走，别跳：

1. 确认解释器是32位：

   import struct print(struct.calcsize("P") * 8)

   输出32还是继续检查，输出64说明你用错了环境。

2. 确认已安装的gdal包架构：

   python -m pip list

   看GDAL版本号是否有cp27或win32的标记。

3. 检查C:\Python27\ArcGIS10.2\Lib\site-packages\osgeo\目录下有没有gdal的pyd文件。正常情况会有一堆gdal*.pyd。如果目录为空或文件大小异常，卸载重装。

4. 安装了Microsoft Visual C++ 2008 Redistributable（x86），这一步很关键但不常被提及。

5. 再执行导入测试。如果还报错，使用Dependency Walker查看gdal203.dll的依赖项是否完整。不过这个工具较老，也可以用Dependencies这个开源替代品。不过对于大部分场景，走到步骤4基本就能解决了。

6.3 版本不匹配造成的“隐形错误”

还有一种更隐蔽的情况：机器上装有另一个Python 2.7（比如Anaconda 2或ESRI还有其他插件装的Python），并且它的Scripts目录也在PATH里。你敲pip install gdal时，可能装到了那个环境的site-packages，然后你用ArcGIS的python.exe去import，自然是找不到的。

排查方法很简单：

where python where pip

看看实际找到的第一个python和pip指向哪里。如果指向的不是C:\Python27\ArcGIS10.2\，那就说明PATH顺序出问题了。把ArcGIS Python路径调整到最前即可。

6.4 Python 2.7时代特有的编码坑

在Python 2.7里，字符串的默认编码是ASCII，遇到中文路径或中文字符串时极易抛UnicodeDecodeError或者UnicodeEncodeError。这个问题在ArcGIS环境里尤其常见，因为地理数据路径含中文的概率很高。

建议在所有脚本开头统一加上：

# -*- coding: utf-8 -*- import sys reload(sys) sys.setdefaultencoding('utf-8')

这算是Python 2.7时代的"土办法"，但确实有效。需要注意的是，Python 2.7的reload(sys)和setdefaultencoding('utf-8')仅仅是把解释器默认编码改了，并不能让每个第三方库都自动处理编码问题。更稳妥的办法是：路径字符串用u"..."前缀写成Unicode，文件读写时显式指定编码，比如open(fp, 'rb')或者codecs.open(fp, 'r', 'utf-8')。

7. 进阶配置：让老环境用得稍微舒服一点

环境配置好了，只是起点。后续日常使用中还有几个值得做的优化项，我根据自己的经验逐个说。

7.1 把Scripts加入PATH，让命令行交互更顺手

前面提过，这一步很基础但也容易忘。操作路径是：右键"此电脑"→属性→高级系统设置→环境变量→编辑Path→新建两条：

C:\Python27\ArcGIS10.2 C:\Python27\ArcGIS10.2\Scripts

保存后重开命令行，直接敲python和pip应该都能识别。

7.2 正确管理多个Python环境的PYTHONPATH

如果你机器上同时有Python 3和ArcGIS自带的Python 2.7，建议不要手动设置全局PYTHONPATH，因为那会导致两个环境互相污染。正确的做法是：需要哪个环境就在对应环境的site-packages里装包，调用时用python -m pip，并且不要设置可能会串环境的PYTHONPATH项。

7.3 做一个环境一键检测脚本

为了快速判断环境是否正常，可以把下面这段脚本存成check_env.py，需要时跑一下：

# -*- coding: utf-8 -*- import sys print("Python:", sys.version) try: import arcpy print("arcpy OK:", arcpy.GetInstallInfo()["Version"]) except Exception as e: print("arcpy FAIL:", e) try: from osgeo import gdal print("gdal OK:", gdal.__version__) except Exception as e: print("gdal FAIL:", e) try: import pip print("pip OK:", pip.__version__) except Exception as e: print("pip FAIL:", e)

执行：

C:\Python27\ArcGIS10.2\python.exe check_env.py

看到三项都OK，说明环境基本健康。如果哪天脚本跑不起来了，优先用这个脚本定位问题的范围。

7.4 备份site-packages，快速恢复环境

ArcGIS的Python环境虽然不能像Anaconda那样方便地导出环境快照，但可以把整个C:\Python27\ArcGIS10.2\Lib\site-packages目录压缩备份一份。遇到环境被搞坏、重装系统等情况，解压回去就能恢复大半。虽然听起来有点土，但确实是我用过最靠谱的恢复方案。在某些严格的单位内网环境里，没法随便下载包，备份包文件几乎是唯一出路。具体操作：把site-packages压缩包放在网络盘或移动硬盘上，同时把C:\Python27\ArcGIS10.2\Scripts里的exe和dll也备份一份，因为有些包（比如gdal的脚本工具）会安装到那里。

7.5 VSCode里指向老Python环境

现在很多人写脚本用VSCode，想在里面选择ArcGIS的Python 2.7.5解释器，只需在VSCode里通过命令面板选"Python: Select Interpreter"，然后在路径列表里找到C:\Python27\ArcGIS10.2\python.exe，或者直接输入该路径。选好之后，VSCode右下角会显示当前解释器路径。同时建议安装Python插件后，把"python.pythonPath"显式设为ArcGIS的解释器路径。

有一点需要注意：VSCode的Python插件最新版本对Python 2.7的支持已经非常有限，有时会出现调试器不兼容、代码提示失效的问题。如果想省心，可以直接用更轻量的编辑器配命令行执行，或者用旧版本的VSCode扩展。当然，单纯用来写代码，不做调试的话，问题不大。

8. 一些零碎但重要的经验备忘

最后这部分，写一些不一定成体系，但实际用下来确实能减少麻烦的零碎经验。

第一，能不重装系统就尽量不要重装。重装后ArcGIS的许可服务经常出问题，而Python环境也可能因为注册表项丢失而导致arcpy无法使用。如果你必须重装，事先把ArcGIS的安装包、许可服务程序、Python site-packages备份都准备好，会省下至少半天的恢复时间。

第二，安装任何第三方库前，先看一下它是否依赖C++运行库。比如pyshp、shapely、Pillow这些库都可能依赖特定的VC++版本，而32位Python 2.7通常对应的是VC++ 9.0。本身ArcGIS自带的Python是用VS2008编译的，所以装新包时最好匹配同一个编译链的版本，不然DLL问题会一波接一波。

第三，如果你打算用arcpy做大数据量处理，先测一下内存和临时目录空间。这个问题跟Python环境本身无关，但很多老机器跑着跑着就报错，根因其实是临时目录被占满。ArcGIS的栅格处理工具在工作时会生成大量临时文件，默认临时目录在C:\Users\你的用户名\AppData\Local\Temp，如果系统盘空间不足，处理就会中途挂掉。可以在脚本里设置arcpy.env.scratchWorkspace指向另一块空间充足的磁盘。

第四，在国内网络环境下，pip源配置要是还没做，赶紧做。不配源的话，光装一个几十MB的gdal wheel可能就要反复重试几个小时，配好源之后基本是秒级下载。这条经验在今天同样适用，跟是不是老环境无关。

要说这套环境还能用多久，我个人觉得，它作为一个"历史遗留系统"的配套工具，还会存在相当长一段时间。数据不会因为软件版本老就不见了，业务流程也不会因为Python 2.7停止维护就立刻切换。所以，把环境盘明白了，该写脚本写脚本，该出图出图，别被工具版本拖累就行。

另外，如果你实在无法忍受这套老环境的各种限制，但又必须兼容旧数据，可以考虑用Docker容器化一个独立的Python 2.7 + GDAL环境，和ArcGIS Desktop本体分开跑。容器里做数据处理，ArcGIS桌面端负责可视化和编辑，两者通过共享文件目录交换数据，这样能稍微隔离一下老环境的脆弱性。不过这属于另一种玩法了，工作量也不小，属于备选方案。

说到底，工具只是手段，把活干利索才是目的。希望这份配置攻略能帮你少走点弯路。