根本原因是子进程初始化失败：pytorch多进程启动worker时会重新导入主模块，若其中含cuda操作、未保护的训练逻辑、不可pickle资源或非fork-safe库（如opencv、matplotlib），将导致brokenpipeerror、assertionerror或静默卡死。
num_workers设为0以外的值就报错，常见原因是什么
根本问题通常不是num_workers本身写错了，而是子进程初始化失败——PyTorch用multiprocessing启动worker时，会重新导入主模块，如果主模块里有不能被安全重入的代码（比如直接执行的CUDA操作、未加if __name__ == "__main__":保护的训练逻辑），就会崩溃。
典型错误现象包括：BrokenPipeError、AssertionError: Cannot re-initialize CUDA in forked subprocess、ImportError（找不到自定义dataset模块）、或进程静默退出导致DataLoader卡住。
- Windows上必须用
if __name__ == "__main__":包裹DataLoader创建和训练主流程 - Linux/macOS虽宽松些，但若主脚本顶部有
torch.cuda.set_device()或model.to("cuda")，也会在worker中触发CUDA重初始化失败 - 自定义
Dataset类里如果在__init__中加载了大型资源（如整个图像列表+预处理），且该资源不可pickle，worker反序列化时会出错
为什么num_workers=0不报错，但训练变慢
num_workers=0表示所有数据加载都在主进程中同步执行，不启子进程，自然绕过上述初始化问题。但它把I/O和预处理全塞进训练循环，GPU经常等CPU喂数据，显存利用率低、吞吐掉得明显。
这不是“修复”，只是掩盖问题。尤其当__getitem__里有磁盘读图、解码、augmentation时，瓶颈立刻暴露。
- 实测：
num_workers=4常比=0快2–5倍（取决于磁盘速度和transform复杂度） - 但
num_workers不是越大越好，超过CPU核心数后调度开销上升，还可能因内存拷贝竞争拖慢整体 - 建议从
min(4, os.cpu_count() - 1)起步，再按top命令观察CPU/IO负载调整
如何排查具体是哪一行触发的worker崩溃
默认情况下子进程错误被吞掉，只看到主进程hang住或抛出模糊异常。必须显式启用调试模式。
- 临时加
pin_memory=False和num_workers=1，让错误浮到前台 - 在
Dataset.__getitem__最开头加print(f"Loading {index}")，看卡在哪条样本 - 把
DataLoader的timeout设小（如timeout=5），超时后主进程会报RuntimeError: DataLoader timed out after 5 seconds，配合日志定位更准 - 终极手段：用
torch.multiprocessing.set_start_method("spawn")替代默认fork（尤其Windows或涉及CUDA时），但需确保主模块可独立导入
自定义Dataset和Collate_fn容易踩的坑
worker崩溃往往藏在数据准备环节，而非DataLoader参数本身。
-
Dataset.__getitem__里避免使用全局变量（如未封装进类的cv2预处理函数），worker无法共享其状态 - 不要在
__getitem__里打开文件句柄（如open(...)）后不关闭——worker进程退出时可能没释放，导致Too many open files -
collate_fn必须能处理None（比如某些样本因异常返回None），否则default_collate会崩；建议加if batch is None: continue过滤 - 如果用了
torchvision.io.read_image，确认图片路径是绝对路径——worker里当前工作目录可能不是你预期的
真正难调的不是num_workers数值，而是主进程和worker进程之间的环境隔离边界。很多问题表面是DataLoader报错，根子在模块导入时机、CUDA上下文生命周期、或资源初始化方式。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
