PyTorch DataLoader卡在__iter__主因是Linux下fork子进程继承损坏CUDA状态，应改用spawn启动；或共享内存不足，可设pin_memory=False或升级PyTorch。
PyTorch DataLoader卡在 __iter__ 但没报错？检查 num_workers 和共享内存
常见现象是训练启动后卡住几秒甚至几十秒，DataLoader 不吐数据，GPU 闲置，nvidia-smi 显示显存已占但 train_step 没跑。本质是子进程初始化阻塞，尤其在 Linux + 多 num_workers > 0 时高频发生。
-
num_workers=0时一切正常 → 基本锁定是子进程问题，不是数据路径或 transform 错误 - Linux 下默认用
fork启动子进程，若主进程已加载 CUDA 上下文（比如提前调用了torch.cuda.is_available()），子进程会继承损坏的 CUDA 状态 → 改用spawn启动方式：torch.multiprocessing.set_start_method("spawn", force=True)（必须放在if __name__ == "__main__":下且早于任何 CUDA 调用） - Windows/macOS 用户更常遇到
SharedMemory不足：DataLoader默认用共享内存传 tensor，大数据集 + 高batch_size容易撑爆 → 加pin_memory=False或升级 PyTorch（1.12+ 对共享内存管理更稳） - 调试技巧：临时设
num_workers=0看是否跑通；再逐步加到 1、2，观察卡点；配合torch.utils.data.get_worker_info()在Dataset.__getitem__里打日志定位具体哪条样本卡住
RandomHorizontalFlip 为什么没生效？transform 顺序和 PIL/Tensor 类型不匹配
写了 RandomHorizontalFlip(p=1.0) 却发现图像从不翻转，或者翻转后变黑/错位——大概率是输入类型不对，或和其他 transform 冲突了。
-
RandomHorizontalFlip只接受PIL.Image或torch.Tensor（CHW 格式），如果你在ToTensor()之前就调用它，会直接抛TypeError: img should be PIL Image；反过来，如果在ToTensor()之后调用，它也能处理 tensor，但必须确保 tensor 是float32且值域在 [0,1]（ToTensor()默认归一化到此范围） - 别把
RandomHorizontalFlip和RandomRotation这类空间变换放在Normalize()之后 ——Normalize依赖固定均值方差，翻转本身不影响统计量，但若你自定义了 per-image normalize 就可能出问题 - 验证是否生效：在
Dataset.__getitem__返回前加print(sample_tensor[0, :3, :3])（取左上角像素），连续看两个 batch，翻转后第一行像素应变成最后一行
自定义 Dataset 的 __getitem__ 里做 heavy IO 怎么提速？缓存 + prefetch + lazy load 组合用
读 HDF5/大 TIFF/远程 S3 文件时，单次 __getitem__ 耗时 >100ms，DataLoader 再多 worker 也救不了吞吐 —— 瓶颈不在 CPU/GPU，而在磁盘或网络延迟。
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 优先用内存映射：HDF5 用
h5py.File(..., swmr=True)+ds = f["data"][idx]（不 load 全量）；TIFF 用tifffile.memmap() - 小文件（self.data = [np.load(p) for p in self.paths]，但注意 OOM 风险，可用
psutil.virtual_memory().available估算余量 - 远程数据（S3/HTTP）务必加缓存层：
torch.hub.load_state_dict_from_url(..., cache_dir="./s3_cache")或自己用diskcache库按 hash 缓存响应体 - 避免在
__getitem__里重复打开/关闭文件句柄 —— 把open()提到__init__，复用 file object（注意线程/进程安全，num_workers>0时每个 worker 有独立副本）
collate_fn 写错导致 RuntimeError: stack expects each tensor to be equal size？
当 batch 中图像尺寸不一致（比如检测任务中不同分辨率的图，或 padding 前的 mask），default_collate 会直接报 stack 失败 —— 它不做 resize/pad，只尝试 torch.stack()。
立即学习“Python免费学习笔记（深入）”；
- 最简解法：写一个
collate_fn对list[torch.Tensor]做统一 resize（F.interpolate）或 pad（F.pad），但注意不要在 collate 里调.cuda()—— 设备转移应留给模型 forward 前做 - 检测/分割任务推荐用
torchvision.ops.misc.nested_tensor_from_tensor_list（PyTorch 1.10+），它保留各 tensor 原始 shape，返回NestedTensor，后续可被专用算子消费 - 别在
collate_fn里做 augmentation —— 那属于 per-sample 行为，放Dataset.__getitem__更合理；collate 只该干“对齐”和“合并”两件事 - debug 技巧：在 collate_fn 开头加
print([x.shape for x in batch])，一眼看出哪些维度不一致（H/W 不同？channel 数不一？）
真正难调的永远不是单个 API 怎么用，而是多个机制叠加后的隐式耦合：比如 num_workers 触发的 fork/spawn 差异、pin_memory 和 GPU 显存分配策略的交互、甚至 Linux cgroups 限制了子进程能用的内存上限。这些地方没报错，但慢得离谱，得靠 strace -p $(pgrep -f "python train.py") 或 torch.utils.bottleneck 才挖得出来。
