在 Windows 平台使用 PyTorch 的 DataLoader 时，经常遇到程序启动之后一直卡死、无法吐出第一个 batch 的现象，这个问题绝大多数都来自 Windows 的多进程生成机制差异，和 Linux 的 fork 不一样，Windows 默认使用 spawn，一旦代码写法不对、全局变量或者 CUDA 资源在主进程提前加载，就会直接卡住数据加载流程；本篇把这个高频踩坑点完整拆解，包含识别手段、多种修复方案以及可直接套用的代码写法，帮 AI 工程师快速定位并且解决 DataLoader 卡在第一个 batch 的问题。
Windows 下为什么容易卡住第一个 batch
Linux 多进程默认 fork，子进程复制当前进程内存上下文。Windows 没有 fork，只能走 spawn：启动全新 Python 解释器，重新导入所有代码。
如果数据集、模型、CUDA 张量放在模块全局作用域，子进程导入脚本的时候会重复执行这部分逻辑。一旦里面包含 CUDA 初始化、文件锁、未保护的 IO、无限循环，子进程就会阻塞。表现就是主进程等待子进程返回数据，永远拿不到第一个 batch。
另外几个高频诱因：
- num_workers > 0，但是没有把加载逻辑放进 if __name__ == "__main__"；
- 在全局位置初始化 CUDA、创建 cuda tensor；
- 自定义 Dataset 里面有不可序列化对象；
- 开启 persistent_workers，配合有状态全局变量；
- 杀毒软件、文件夹权限阻止子进程读取数据集。
标准排查与修复步骤
- 先缩小范围验证：把 num_workers 设置为 0，如果不再卡死，基本锁定就是 Windows 多进程 spawn 带来的问题。
- 代码入口保护：所有训练、DataLoader 实例化逻辑，全部包裹在 if __name__ == "__main__": 内部。
- 延后 CUDA 初始化：不要在全局、类定义顶层创建 CUDA 张量，放到训练循环内部或者被懒加载的函数里。
- 检查 Dataset 可序列化：自定义数据集不要携带文件句柄、网络连接、锁对象；尽量只保存路径，在 __getitem__ 内部打开文件。
- 切换多进程启动方式（谨慎）：可以尝试设置 torch.multiprocessing.set_start_method("spawn")，Windows 默认就是这个，不要强行改成 fork。
- 精简 worker 初始化：如果使用 worker_init_fn，只放必要的随机种子固定逻辑，不要做重型加载。
- 测试最小样例：用内置的 TensorDataset 写最小复现脚本，确认是数据集代码还是外部依赖导致阻塞。
实用配置参考表
| 参数 | 推荐（Windows） | 说明 |
|---|---|---|
| num_workers | 0～2 | 不建议直接拉很高，越高越容易触发 spawn 异常 |
| persistent_workers | False | 新手先关闭，稳定后再开启 |
| pin_memory | True | 本身不卡死，但如果 CUDA 资源冲突会放大问题 |
| start_method | spawn | Windows 唯一可用，不要强行修改 |
| Dataset 加载 | 在 __getitem__ 读文件 | 避免全局预加载大文件 |
额外调试手段
如果修改完入口保护之后依旧卡死，可以在 worker 函数开头加入打印，看子进程到底卡在哪一行。还可以使用 torch.utils.data._utils.worker 的日志，观察 worker 是否成功启动。
很多 AI 工程师第一次碰到这个坑，会误以为是数据集损坏或者磁盘太慢，反复换数据集却没有效果。只要平台是 Windows，并且一开多 worker 就卡在第一个 batch，优先怀疑 spawn 机制。
整体来说，这个坑属于 PyTorch 跨平台差异的经典问题，核心规则很简单：Windows 的子进程会重新跑脚本，凡是不能安全重复执行的代码，都必须放到主保护分支之内。
【常见问题】
问题 1：DataLoader 卡在第一个 batch，只要开启 num_workers 就复现，是不是全部都是 Windows 多进程 spawn 的问题？
回答 1：绝大多数场景是 Windows 多进程 spawn 引发的，但也有可能是数据集文件锁、损坏样本、全局 CUDA 初始化叠加导致，优先把 num_workers 置零来区分。
问题 2：把代码放进 if name == "main"，能不能根治 Windows 上 DataLoader 卡在第一个 batch？
回答 2：这是最核心修复手段，如果同时还存在全局 CUDA 张量、不可序列化对象，就算加上这个保护，DataLoader 依然有可能卡在第一个 batch，需要同步清理全局加载逻辑。
问题 3：如果我一定要在 Windows 使用多 worker，同时不想 DataLoader 卡在第一个 batch，有没有长期稳妥写法？
回答 3：坚持把训练入口放进主保护块，数据集只保存路径，在取样本的时候再加载，不在顶层初始化 CUDA；如果对速度要求不高，直接使用 num_workers=0，彻底避开 Windows 多进程陷阱。
【参考资料】
[2026-10-18]（PyTorch DataLoader 在 Windows 多进程下阻塞首 batch 排查记录）PyTorch 中文论坛
[2026-09-23]（Windows spawn 机制：DataLoader num_workers 踩坑指南）知乎 AI 工程专栏
[2026-08-07]（PyTorch 官方文档：Windows 平台多进程启动方式说明）PyTorch Docs
【免责声明】
本资讯为工程踩坑参考，不同 PyTorch 版本、CUDA 版本、Windows 系统版本、磁盘环境都会影响表现；文中方案优先用于复现并定位问题，正式上线前需要在目标环境完整跑通多轮训练验证。