直接继承Dataset爆内存是因为在__init__中预加载全部图像，正确做法是仅在__getitem__中按需加载单张图并及时释放资源，同时避免worker重复拷贝、错误collate_fn和调试触发解码等隐性内存泄漏。
为什么直接继承 Dataset 会爆内存
PyTorch 的 Dataset 默认不加载数据，只存路径或索引，但很多人在 __init__ 里就用 PIL.Image.open() 或 cv2.imread() 把所有图片读进内存，尤其当有 10 万张 4K 图时，__init__ 阶段就 OOM。真正该做的，是把解码动作严格推迟到 __getitem__ 中——而且仅对当前 batch 所需的那几张。
__getitem__ 必须只做三件事：路径解析、单图加载、基础变换
__getitem__ 是唯一该触发图像 I/O 的地方，且必须保证每次调用只处理一张图。常见错误包括在里面做批量 resize、拼接多图、甚至调用 torch.stack ——这些都该交给 DataLoader 的 collate_fn 或后续模型处理。
- 用
os.path.join(self.root, self.img_list[idx])拼路径，别提前存全量PIL.Image对象 - 加载用
Image.open(path).convert('RGB')，立刻.close()（尤其 Windows 下文件句柄易耗尽） - 变换统一走
torchvision.transforms，别手写np.array(img) / 255.0——后者不支持 lazy tensor，且易漏.permute(2,0,1) - 若需不同尺寸/格式（如灰度+RGB混合），在
__getitem__内按self.mode分支处理，别试图预存多种版本
懒加载失效的四个隐蔽原因
即使写了正确的 __getitem__，仍可能因外部干扰导致“假懒加载”：表面没崩，实则内存持续上涨。
-
DataLoader(num_workers > 0)时，每个 worker 会预拷贝整个Dataset实例——如果__init__里存了大对象（如self.class_to_idx是百万级 dict），worker 进程会重复占用；应改用functools.lru_cache或按需查表 - 用了
torchvision.datasets.ImageFolder子类却重写了__init__却忘了调用super().__init__()，导致底层self.samples被绕过，路径列表被重复生成 - 自定义
collate_fn中调用了item.numpy()或item.cpu().numpy()，触发 tensor 脱离计算图并驻留内存；应改用item.detach().cpu()+ 显式del item - 日志或调试代码在
__getitem__里打印img.shape——看似 harmless，但 PIL Image 的.size不触发解码，而np.array(img)会；务必用img.width/img.height
超大数据集必须加路径缓存与校验
当图片总数超 50 万，每次 __getitem__ 都 os.path.exists() 会拖慢 3–5 倍。但全量缓存路径又怕磁盘变更失效。折中方案是：首次构建时生成轻量索引文件，含路径哈希与 mtime，后续只比对 mtime。
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
立即学习“Python免费学习笔记（深入）”；
# 示例：安全的路径缓存
import pickle, os, time
cache_path = f"{root}/.index.pkl"
if os.path.exists(cache_path):
with open(cache_path, "rb") as f:
cached = pickle.load(f)
if all(os.path.getmtime(p) == m for p, m in cached.items()):
self.img_list = list(cached.keys())
return
# 否则重新扫描并保存
注意：不要缓存 Image.open() 返回的对象，也不要存完整绝对路径（跨机器失效），用相对路径 + self.root 拼接更健壮。
最麻烦的永远不是怎么写 __getitem__，而是确认它真的没被任何地方提前触发——建议用 tracemalloc 在 dataloader 循环里打点，看内存增长是否严格与 batch 数成正比。
