懒加载的关键是__getitem__里做单样本加载：仅在该方法中按索引读取文件，路径列表存于self.file_paths，__len__返回其长度；避免全局句柄、未隔离随机种子及大文件格式误用。
懒加载的关键是 __getitem__ 里做单样本加载
PyTorch 的 Dataset 不强制要求所有数据进内存，核心在于把加载逻辑从 __init__ 搬到 __getitem__。常见错误是初始化时就用 np.load 或 cv2.imread 把全部文件读进内存，导致 OOM。正确做法是只在 __getitem__ 中按索引打开对应文件——哪怕每次都要磁盘 IO，也比全量加载安全。
典型场景：处理数万张图像、TB 级医学影像或长视频帧序列。这时 self.data_list 只存路径（list[str]），不存像素数组。
- 路径列表建议用绝对路径，避免工作目录切换导致
FileNotFoundError - 不要在
__getitem__里做耗时预处理（如 resize、normalize），放到transforms中更易复用和调试 - 若需缓存少量热门样本，可用
functools.lru_cache包裹加载函数，但注意maxsize设太大会抵消懒加载效果
__len__ 必须返回真实样本数，不能依赖内存数据长度
懒加载后 len(self) 很容易写错：有人直接返回 len(self.data)，但此时 self.data 是路径列表，没问题；更隐蔽的坑是误用 len(os.listdir(...)) 在初始化时硬编码数量，结果目录后期增删文件却没更新 __len__，导致 DataLoader 迭代时索引越界或漏样本。
推荐做法是在 __init__ 中一次性扫描并固化路径列表，再返回其长度：
self.file_paths = [os.path.join(root, f) for f in os.listdir(root) if f.endswith('.npy')]
这样 __len__ 就简单返回 len(self.file_paths)，稳定且可复现。
- 避免在
__len__里实时调用os.listdir——多进程加载时可能因文件系统延迟返回不一致结果 - 如果数据源是数据库或远程存储（如 S3），
__len__应缓存查询结果，不能每次调用都发请求
多进程 DataLoader 下的文件句柄与随机种子问题
启用 num_workers > 0 后，每个子进程会独立执行 __getitem__，若你在里面用了全局文件句柄（比如提前 open() 一个日志文件）、或依赖未隔离的随机状态（如 random.shuffle），就会出竞态或复现性问题。
典型错误现象：OSError: Too many open files，或训练时 augment 结果每 epoch 都不同，即使设置了 generator。
- 所有文件操作必须在
__getitem__内部完成：打开 → 读取 → 关闭，别复用句柄 - PyTorch 1.7+ 要求为每个 worker 显式设置随机种子，在
worker_init_fn中调用torch.manual_seed(worker_id + seed) - 避免在
Dataset类里定义可变类属性（如cache = {}），它会在所有 worker 间共享，引发数据污染
大文件格式（如 HDF5、LMDB）要额外注意访问模式
用 h5py.File 或 lmdb.Environment 加载单个样本时，不能在 __init__ 中全局打开文件对象——那会把整个 HDF5 文件映射进内存，或者让 LMDB 环境被多个进程同时写入而崩溃。
正确姿势是：在 __getitem__ 中临时打开、读取、关闭。对 HDF5，用 h5py.File(path, 'r')；对 LMDB，用 env.begin(write=False)。
- HDF5 文件若含上万 dataset，每次
h5py.File开销大，可考虑用h5py.File(..., swmr=True)启用单写多读模式 - LMDB 推荐设
map_size大于总数据量，否则put时扩容会阻塞所有 worker - 避免在
__getitem__中反复open/close同一个 HDF5 文件——可改用文件路径 + group/key 字符串组合，由子进程各自管理生命周期
懒加载不是银弹：IO 成为瓶颈时，模型吞吐反而下降。真正关键的是分清「必须懒」（内存扛不住）和「可以懒」（只是习惯性规避）。路径、句柄、随机性、文件格式——这四点踩错任意一个，都会让懒加载变成假懒或死锁。
