使用gdal打开geotiff等栅格文件后，若未显式关闭数据集对象（如`band1_ds`），操作系统会持续锁定文件，导致后续调用`os.remove()`时抛出“文件正被另一个进程使用”错误。关键在于调用`.close()`方法或置为`none`——但必须作用于原始gdal dataset对象变量。
在GDAL中，gdal.Open()返回的是一个持久的Dataset对象，它不仅加载元数据，还会在底层维持对文件句柄（file handle）的引用。即使你将读取后的NumPy数组（如Band1）设为None，原始Band1_ds对象仍驻留在内存中并持有文件锁——这正是你遇到The process cannot access the file because it is being used by another process的根本原因。
✅ 正确做法是：显式关闭每个GDAL Dataset对象，推荐使用 dataset.Close()（GDAL ≥ 3.6）或兼容性更强的 del dataset / dataset = None，且必须作用于打开时声明的变量名（如Band1_ds），而非其派生数组（如Band1）。
以下是修复你代码的关键修改点（已整合最佳实践）：
# ✅ 替换原代码中所有 gdal.Open(...) 后的处理逻辑：
Band1_ds = gdal.Open(f'{extract_path}/{extract_name[i]}')
if Band1_ds is not None:
Band1 = Band1_ds.ReadAsArray().astype(float)
Band1[Band1 < 0] = np.nan
Band1_ds = None # ? 关键：释放 Band1_ds！不是 Band1
# 同理处理其他波段：
Band2_ds = gdal.Open(...)
if Band2_ds is not None:
Band2 = Band2_ds.ReadAsArray().astype(float)
Band2[Band2 < 0] = np.nan
Band2_ds = None # ? 必须是 Band2_ds = None
# ... Band3_ds, Band4_ds 同理⚠️ 注意事项：
- 不要依赖 gc.collect() 或 del 隐式清理：Python垃圾回收不保证立即释放GDAL底层资源；显式置None是最可靠方式。
- 检查 gdal.Open() 返回值：避免对None调用.ReadAsArray()引发AttributeError。
-
GDAL ≥ 3.6 可用 .Close() 方法（更语义化）：
Band1_ds = gdal.Open(path) # ... processing ... Band1_ds.Close() # 显式关闭，推荐新项目使用
- 批量关闭更安全：可在处理完所有波段后统一置None，但务必覆盖全部*_ds变量（如Band1_ds, Band2_ds, Band3_ds, Band4_ds），遗漏任一都将导致对应文件无法删除。
? 进阶建议：
使用上下文管理器可大幅提升健壮性（需GDAL ≥ 3.4 + gdal.Dataset 支持 __enter__/__exit__）。若环境允许，可封装为：
from contextlib import contextmanager
@contextmanager
def gdal_dataset(path):
ds = gdal.Open(path)
try:
yield ds
finally:
if ds is not None:
ds = None
# 使用方式：
with gdal_dataset(f'{extract_path}/AR_BAND1.tif') as ds:
Band1 = ds.ReadAsArray().astype(float)
Band1[Band1 < 0] = np.nan
# 自动关闭，无需手动置 None总结：GDAL文件锁问题本质是资源管理疏漏。牢记——“谁打开，谁关闭”，且关闭目标必须是gdal.Open()返回的Dataset变量本身。修复后，os.remove()即可正常清理临时文件，流程彻底解耦、稳定可靠。
