结论：需零拷贝且双向同步用torch.from_numpy()；需智能fallback（dtype或device不兼容时自动拷贝）用torch.as_tensor()；需完全隔离用torch.tensor()。from_numpy仅接受CPU上np.ndarray，强制共享内存、严格继承dtype、不支持device指定，修改互见；as_tensor按需共享或拷贝；tensor无条件深拷贝，易致OOM。
直接说结论：想零拷贝、双向同步改数据，用 torch.from_numpy()；想尽量零拷贝但允许自动 fallback 到拷贝（比如 dtype 不匹配或要上 GPU），用 torch.as_tensor()。硬拷贝（完全隔离）就用 torch.tensor() —— 它不共享内存，改一个不影响另一个。
什么时候必须用 torch.from_numpy()
仅当输入是 CPU 上的 np.ndarray，且你明确需要「内存共享 + 双向修改生效」时才该用它。这是最激进的零拷贝方式，也是唯一强制共享的 API。
- 它只接受
np.ndarray，传 Python list 或标量会报TypeError: expected np.ndarray (got list) - 返回张量的
dtype严格继承 NumPy 数组类型，不能指定新dtype（传了会忽略） - 返回张量只能在 CPU 上，传
device="cuda"会直接报错RuntimeError: can't convert a tensor with device type 'cuda' from numpy - 修改张量元素会立刻反映到原 NumPy 数组，反之亦然 —— 这是它的核心价值，也是最大风险点
torch.as_tensor() 的真实行为边界
torch.as_tensor() 看似更“智能”，实则规则明确：能共享就共享，不能共享就拷贝。它不是“有条件零拷贝”，而是“按需决定是否零拷贝”。
- 输入是
np.ndarray且目标dtype和device兼容（即同为 CPU、且 dtype 可无损映射），则共享内存 → 零拷贝 - 输入是
np.ndarray但指定了不同dtype（如np.int32→torch.float32），则必须拷贝 → 深拷贝 - 输入是
np.ndarray但指定了device="cuda"，则必须分配新显存 → 深拷贝（且原数组不受影响） - 输入是 Python list / tuple / scalar，一律深拷贝（
torch.as_tensor([1,2,3])和torch.tensor([1,2,3])行为一致）
为什么不用 torch.tensor() 做转换？
因为它是无条件深拷贝，哪怕你只是想把一个大图数据从 NumPy 丢进模型做推理，torch.tensor() 也会多占一倍内存 —— 这在图像、视频、医疗影像等场景下极易 OOM。
立即学习“Python免费学习笔记（深入）”；
- 它对任何输入（包括
np.ndarray）都新建内存块，原数组修改永远不影响张量 - 它会尝试推断
dtype，但推断逻辑有时反直觉（比如np.array([1,2,3], dtype=np.int64)→torch.int64，而很多模型默认期待torch.float32） - 它不接受
device参数直接迁移，必须先建再用.to("cuda")，这又触发一次拷贝 - 性能敏感路径（如 dataloader 中的预处理）应避免它处理原始 NumPy buffer
容易被忽略的关键细节
零拷贝不是“设了就完事”，它依赖底层内存布局和生命周期管理。最常踩的坑是：NumPy 数组被 GC 或提前 del 掉，而张量还在用那块内存 —— 此时读写行为未定义，可能 crash，也可能静默返回脏数据。
-
torch.from_numpy()返回的张量与原数组绑定同一内存，若原数组超出作用域（如函数返回后局部变量销毁），张量变成悬垂指针 -
torch.as_tensor()在 dtype 不匹配时悄悄转成拷贝，你以为零拷贝，其实没省下内存 —— 务必用.data_ptr() == your_np_array.__array_interface__['data'][0]实测验证 - 所有零拷贝方式都不支持跨设备共享（CPU↔GPU），所谓“共享”只存在于同一设备内
- 如果你在多线程中同时读写共享内存的张量和 NumPy 数组，必须自己加锁 —— PyTorch 不提供线程安全保证
