最近在给项目环境安装 PyroSAR 时遇到一个 GDAL 依赖问题，运行脚本时直接报错：
ModuleNotFoundError: No module named '_gdal_array'
这个错误最直观的表现就是 GDAL 的 Python 扩展模块没加载成功，而 _gdal_array 正好属于 GDAL 的底层二进制扩展。PyroSAR 本身依赖 GDAL，如果这个模块缺失，不管是读写 GeoTIFF、解析元数据还是处理 SAR 数据，都会全部失败。
我一开始以为是 PyroSAR 装坏了，但检查之后发现问题根本不在 PyroSAR，而是系统里的 GDAL 安装并不完整。Python 在 import gdal_array 时能找到纯 Python 的接口文件，却找不到对应的 _gdal_array.so 扩展文件，多半是被之前的版本覆盖、或者 pip 缓存里存了残缺的 wheel，导致 GDAL 的 Python Bindings 不完整。
实际解决方式很简单，就是把 GDAL 彻底重装一遍，不过不能直接 pip install，需要让 pip 强制抛弃所有本地缓存，把 GDAL 完整重新编译。
使用 uv 的方式如下：
uv pip install setuptools wheel
uv pip install --force-reinstall --no-cache-dir --no-build-isolation gdal==3.4.1
装完之后，再运行同样的代码，问题就消失了。
为什么这样做有效呢？
主要是因为 GDAL 的 Python 模块是由一部分 Python 文件和一部分 C++ 编译的二进制扩展共同组成的，而 _gdal_array 就属于后者。只要编译产物版本不一致或者缺失，这个错误就必然出现。重新安装 GDAL 时加上 --force-reinstall 可以把旧版本全部覆盖，--no-cache-dir 能避免 pip 使用错误的缓存，--no-build-isolation 则让构建过程直接使用当前环境的编译链，不再被隔离环境影响。最终生成的 GDAL 扩展文件是完整的，Python 也就可以正常加载 _gdal_array 了。
GDAL 3.4.1 这个版本和 PyroSAR 的兼容性比较稳，所以指定版本能少踩很多坑。
整个问题本质上就是 GDAL 的 Python Bindings 装得不干净。PyroSAR 只是把问题暴露出来了，重新构建 GDAL 则把文件补齐了。这样的小坑在地理数据相关的 Python 环境里算是家常便饭，也算是一次记录下来给后续查环境的人少走弯路。