num_workers=0时DataLoader“卡住”是因为数据加载完全在主线程同步执行，若Dataset.__getitem__含阻塞操作（如未缓存HDF5读取、cv2.imread大图）就会阻塞训练；这是预期行为而非bug，需避免I/O、提前缓存、加超时等优化。
为什么 num_workers=0 时 DataLoader 看起来“没反应”或卡住？
根本原因不是代码写错了，而是 num_workers=0 表示完全禁用子进程，所有数据加载逻辑都在主线程同步执行。一旦你的 Dataset.__getitem__ 里有阻塞操作（比如读取未缓存的 HDF5 文件、调用 cv2.imread 加载大图、或依赖全局锁的第三方库），主线程就会卡住，训练看起来“停了”。这不是 bug，是预期行为——只是容易被误认为是死锁。
-
num_workers=0下，__getitem__和collate_fn都在训练主进程中调用，无法并行 - Windows 上尤其敏感：某些文件系统操作（如
pathlib.Path.exists()）在多线程下可能触发隐式锁 - 如果你用了
torch.multiprocessing.set_start_method('spawn')，但又设num_workers=0，那这个设置其实被绕过了，不会报错但也没生效
哪些场景必须用 num_workers=0？
不是所有情况都能随便开多进程。以下几类问题会直接导致 num_workers>0 崩溃，只能退回到 num_workers=0：
- 使用了不可 pickle 的对象（比如 lambda 函数、带闭包的函数、某些数据库连接句柄）作为
Dataset成员或collate_fn - 在
__getitem__中调用了依赖 CUDA 的操作（例如torch.cuda.current_device()），因为子进程不继承 CUDA 上下文 - 调试阶段想单步跟踪
__getitem__：开多进程会让 debugger 失效或跳转混乱 - Jupyter Notebook 中启动
DataLoader：部分环境对 fork/spawn 支持不完整，num_workers>0可能卡在__getstate__
num_workers=0 下如何避免卡死？
关键不是“让它快”，而是“让它不阻塞主线程”。最有效的方式是把耗时操作提前做完，让 __getitem__ 变成纯内存访问：
- 图像路径 → 提前用
PIL.Image.open().convert('RGB')读入内存，缓存为np.ndarray或torch.Tensor（注意显存/内存权衡） - HDF5 / LMDB 数据 → 在
__init__中打开句柄并预读索引，避免每次__getitem__都file.__enter__() - 避免在
__getitem__里做任何磁盘 I/O、网络请求、或调用time.sleep()类调试代码 - 如果必须动态加载，加超时和重试：用
try/except包住requests.get(..., timeout=3)，别让它无限等
验证 num_workers=0 是否真在工作
很多人以为卡住就是出错了，其实可能是数据加载太慢，你得确认它是否真的在动：
立即学习“Python免费学习笔记（深入）”；
- 在
Dataset.__getitem__开头加一行print(f"Loading {idx}")，观察输出是否连续出现（不是每 batch 才打一次） - 用
torch.utils.data.DataLoader(..., pin_memory=False)，排除 pinned memory 初始化卡住的干扰 - 临时把
batch_size=1，看单条样本能否顺利返回，再逐步放大 - 检查
len(dataset)是否返回正确值：若为 0 或负数，DataLoader会静默停止迭代
真正麻烦的不是 num_workers=0 本身，而是它把所有数据加载的缺陷都暴露在主线程里——你没法靠开更多进程来掩盖低效实现。
