torch.from_numpy() 有时变慢是因为非C-contiguous或dtype不匹配时会静默触发内存复制；应检查arr.flags.c_contiguous，用np.ascontiguousarray()或torch.as_tensor()避免。
torch.from_numpy() 为什么有时反而变慢？
它本身不拷贝，但一旦原始 NumPy 数组不是 C-contiguous（行主序）或 dtype 不匹配，PyTorch 就会悄悄触发一次完整内存复制——你根本看不到报错，只看到训练卡顿、内存飙升。
常见触发场景包括：np.transpose()、np.flip()、np.rot90() 后的数组，或者用 np.array(..., order='F') 创建的列主序数组。这些操作通常返回视图（view），但底层内存不连续，torch.from_numpy() 拒绝共享，只能复制。
- 检查是否 contiguous：用
arr.flags.c_contiguous或arr.flags.f_contiguous - 强制转为 contiguous：改用
torch.as_tensor(arr.copy())或显式torch.from_numpy(np.ascontiguousarray(arr)) - 避免中间视图：如果要 transpose，优先在 PyTorch 侧做
tensor.permute()或tensor.transpose()，而不是在 NumPy 里先转再传
torch.tensor() 和 torch.from_numpy() 到底该选哪个？
torch.tensor() 总是拷贝，torch.from_numpy() 只有在安全时才零拷贝——但它不会帮你做类型/布局适配，出问题就静默降级为拷贝。
实际选择逻辑很直接：
立即学习“Python免费学习笔记（深入）”；
- 你确定 NumPy 数组是
float32或int64，且arr.flags.c_contiguous == True→ 用torch.from_numpy() - 你不确定来源（比如来自 PIL、OpenCV、h5py 或 pandas 的输出），或做了切片/transpose → 用
torch.as_tensor(arr)，它比torch.tensor()更智能：能复用内存（如果安全），否则才拷贝，且自动推导 dtype - 需要强制 dtype 或 device → 必须用
torch.tensor(arr, dtype=torch.float32, device='cuda')，但它一定拷贝
CPU 张量转 NumPy 时的 .numpy() 报错怎么解？
错误信息通常是 TypeError: can't convert CUDA tensor to numpy. Use Tensor.cpu() to copy the tensor to host memory first. ——这不是性能问题，而是设备隔离的硬限制。
正确链路只有一条：
- GPU 张量 → 先
.cpu()（这步是同步拷贝到主机内存）→ 再.numpy()（零拷贝，因为此时已是 CPU 张量） - 别写
tensor.cuda().numpy()，也别漏掉.cpu() - 如果只是想看数值，用
tensor.item()（标量）或tensor.detach().cpu().numpy()（确保不带梯度）
DataLoader 多进程下 NumPy 数组泄漏的真实原因
不是 torch.from_numpy() 本身的问题，而是多进程间传递 Python 对象时，NumPy 数组被 pickle 序列化——而某些非 contiguous 或自定义 dtype 的数组，在反序列化后丢失了原始内存结构，导致每个 worker 都生成新副本，越跑内存越多。
根治办法不是改转换函数，而是切断 pickle 路径：
- 把数据预加载成
torch.Tensor（用torch.as_tensor()或torch.from_numpy().clone().detach()），再塞进 Dataset；Tensor 在 multiprocessing 中走的是更高效的共享内存路径 - 或者用
torch.multiprocessing.set_sharing_strategy('file_system')（需在程序最开头设置） - 避免在
__getitem__里动态创建大 NumPy 数组；提前存成 mmap 文件或 HDF5，按需读取小块
.cpu().numpy() 依然会失败或拷贝——判断必须分两步做，缺一不可。 
