windows上dataloader开num_workers>0报permissionerror的根本原因是其不支持fork，pytorch默认用spawn启动子进程，而未加if name == '__main__':保护会导致子进程重复执行脚本、资源抢占或路径解析失败。
为什么Windows上DataLoader开num_workers > 0会报PermissionError？
根本原因是Windows不支持fork方式创建子进程，PyTorch默认用spawn启动worker进程，而某些数据加载逻辑（比如打开文件、调用__getitem__里未加保护的全局资源）在子进程中会因路径解析失败或资源竞争触发PermissionError: [WinError 5] Access is denied。常见于使用h5py、cv2.imread、或自定义Dataset中直接读取相对路径文件时。
必须设置if __name__ == '__main__':保护主模块入口
这是Windows下spawn机制的硬性要求，否则子进程会重复执行整个脚本，导致多次初始化、资源抢占甚至递归启动worker。没加这层保护是90%以上权限报错的根源。
- 所有使用
DataLoader且num_workers > 0的代码，必须包裹在if __name__ == '__main__':块内 - 不要把
DataLoader定义放在模块顶层（即缩进为0的位置） - 如果用Jupyter，
num_workers=0是唯一安全选择——IPython无法满足spawn的入口约束
Dataset.__getitem__里避免依赖全局状态或未序列化对象
子进程无法继承父进程的文件句柄、OpenCV全局状态、h5py文件句柄等。一旦__getitem__里用了这些，就会在worker中触发权限/访问错误。
- 不要在
Dataset.__init__里打开并保存h5py.File或cv2.VideoCapture等句柄；应在__getitem__中每次打开、用完立刻.close() - 避免在
__getitem__里调用os.chdir()、修改sys.path或操作全局logging配置 - 路径一律用绝对路径：用
os.path.abspath()或pathlib.Path(__file__).parent拼接，别依赖当前工作目录
临时方案：关掉多进程但保留主线程预取
当问题一时无法定位，或调试阶段需要快速验证逻辑时，num_workers=0不是退步，而是最稳定的兜底方式。此时PyTorch仍会用主线程做数据预取（通过pin_memory=True和异步GPU搬运），多数小到中等规模训练不会明显卡顿。
- 设
num_workers=0后，务必确认pin_memory=True（尤其GPU训练） - 若仍慢，检查
__getitem__是否做了耗时操作（如解码大图、解析XML）——这才是真正瓶颈，不是worker数的问题 - Windows Subsystem for Linux（WSL2）可绕过此限制，但需完整重装PyTorch+cuDNN，实际成本往往高于重构数据加载逻辑
Windows上并行数据加载的坑不在配置参数，而在子进程能否干净地复现父进程的数据访问上下文。路径、句柄、全局状态，任何一个没处理好，都会在worker里变成Access Denied。别急着调num_workers，先确保__getitem__是纯函数式的。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
