必须显式设worker_init_fn，因为多进程dataloader中子进程不继承主进程随机状态，导致所有worker生成相同增强样本；需用worker_id+主seed为各worker独立重置np/random/torch种子。
为什么 worker_init_fn 在多进程 DataLoader 中必须显式设？
PyTorch 的 DataLoader 开启 num_workers > 0 后，子进程默认不继承主进程的随机状态（如 NumPy、Python random），导致所有 worker 加载出完全相同的增强样本或打乱顺序 —— 这不是 bug，是设计使然。不设 worker_init_fn，你就等于在用多个 identical worker 假装并行。
常见错误现象：torchvision.transforms.RandomHorizontalFlip 在训练时几乎不翻转，或 Dataset.__getitem__ 里用 np.random.randint 总返回同一值。
- 必须用
worker_init_fn为每个 worker 单独设置独立随机种子 - 不能只靠
torch.manual_seed()或全局random.seed()，它们在子进程中无效 - PyTorch 1.7+ 对
torch.Generator有更好支持，但worker_init_fn仍是唯一可控入口
worker_init_fn 怎么写才真正隔离各 worker 随机性？
核心逻辑：利用 torch.utils.data.get_worker_info() 获取当前 worker ID，再据此生成唯一种子。别硬编码、别复用主进程 seed。
实操建议：
- 用
worker_info.id+ 主进程 seed 构造新 seed，比如seed = args.seed + worker_info.id - 对每种随机库分别重置：
np.random.seed(seed)、random.seed(seed)、torch.manual_seed(seed) - 如果用了
torch.Generator（如torch.rand(..., generator=g)），也要在worker_init_fn里新建并保存到全局或 closure 中
示例片段：
def worker_init_fn(worker_id):
worker_info = torch.utils.data.get_worker_info()
args = worker_info.args
seed = args.seed + worker_id
np.random.seed(seed)
random.seed(seed)
torch.manual_seed(seed)
哪些场景下 worker_init_fn 会失效或被绕过？
不是设了就万事大吉。几个典型失效点：
-
num_workers = 0时，worker_init_fn根本不执行 —— 调试时容易误以为“代码没问题”，切记验证实际 worker 数 - 自定义
Dataset在__init__中预加载了带随机性的数据（如提前 shuffle list），此时初始化发生在主进程，worker 读的是同一份已固定结果 - 用了第三方库（如
albumentations）且没在worker_init_fn中调用其 seed 设置（如A.ReplayCompose需额外处理） - Windows 上使用 spawn 启动方式时，若
worker_init_fn引用了未序列化的闭包变量，会报PicklingError
性能与兼容性要注意什么？
worker_init_fn 本身开销极小，但错误实现可能拖慢启动或引发隐性竞争。
- 避免在
worker_init_fn中做耗时操作（如加载文件、创建大对象），它在每个 worker 启动时都执行一次 - PyTorch 1.10+ 对 Windows 的 spawn 模式更严格，确保
worker_init_fn是 top-level 函数，不要嵌套在类方法或 lambda 里 - 如果你用
torch.compile或torch._dynamo，目前worker_init_fn不参与编译，但不影响其运行时行为 - 注意
forkvsspawn：Linux 默认 fork，能继承部分状态；Windows/macOS 默认 spawn，更干净但也更依赖worker_init_fn显式初始化
最常被忽略的一点：worker 的随机种子和主进程训练循环的种子是两套体系，torch.manual_seed 在训练 loop 里调用，不会影响 data loading —— 这个分离是故意的，也是必须手动桥接的。
