使用gdal打开geotiff等栅格文件后，若未显式关闭数据集（如`dataset = none`或`dataset.flushcache()`），操作系统会持续锁定文件，导致后续`os.remove()`报错“the process cannot access the file because it is being used by another process”。
在GDAL中，调用 gdal.Open() 返回的是一个 Dataset 对象（例如 Band1_ds），该对象在Python中被引用时，底层C++驱动会保持对文件的独占访问（尤其在Windows系统上）。仅将读取后的数组变量（如 Band1）设为 None 并不能释放文件句柄——真正需要置为 None 的是原始的 Dataset 对象本身。
在你的代码中，你创建了 Band1_ds, Band2_ds, Band3_ds, Band4_ds 等变量，但在后续清理阶段却只执行了：
Band1 = None Band2 = None Band3 = None Band4 = None
而遗漏了关键的：
Band1_ds = None Band2_ds = None Band3_ds = None Band4_ds = None
✅ 正确做法是在所有 ReadAsArray() 操作完成后、执行 os.remove() 之前，显式解除对 Dataset 对象的引用。GDAL官方文档明确指出：dataset = None 是推荐的关闭方式（等价于 dataset.FlushCache() + 释放资源）。
以下是修复后的核心清理段落（替换原代码末尾的 for filename in os.listdir(...) 前的部分）：
# ... [前面计算 ChloA 和 Turb 的代码保持不变] ...
# ✅ 关键修复：显式关闭所有 GDAL Dataset 对象
Band1_ds = None
Band2_ds = None
Band3_ds = None
Band4_ds = None
# ✅ 可选增强：强制垃圾回收（尤其在循环处理多组文件时）
import gc
gc.collect()
# 现在可安全删除提取的临时文件
for filename in os.listdir(extract_path):
filepath = os.path.join(extract_path, filename)
if os.path.isfile(filepath):
try:
os.remove(filepath)
print(f"Deleted: {filename}")
except PermissionError as e:
print(f"Failed to delete {filename}: {e}")⚠️ 注意事项：
- 不要依赖 del BandX_ds —— 在作用域内 del 后若仍有隐式引用（如异常栈、调试器），仍可能延迟释放；BandX_ds = None 更可靠。
- Windows 对文件锁更严格，Linux/macOS 可能允许删除（但文件句柄仍存在），因此跨平台开发务必统一关闭。
- 若使用 with 语句风格，GDAL 本身不原生支持上下文管理器，但可封装为上下文管理类（进阶实践）：
from contextlib import contextmanager @contextmanager def gdal_open(path, *args, **kwargs): ds = gdal.Open(path, *args, **kwargs) try: yield ds finally: if ds is not None: ds = None # 使用示例： # with gdal_open("AR_BAND1.tif") as ds: # arr = ds.ReadAsArray()
总结：GDAL 文件“被占用”本质是 Dataset 对象未释放所致。牢记——谁 Open()，谁负责 = None。这是 GDAL Python 绑定中最常见也最易忽视的资源管理陷阱。
