view要求张量连续，否则报错；reshape自动处理非连续情况，但可能触发隐式拷贝导致性能下降。
性能差异根本不在函数本身，而在它们对内存连续性的处理逻辑不同：一个拒绝妥协，一个自动兜底。
view 性能高的前提是张量必须连续
view 是纯元数据操作 —— 它只改 shape 和 stride，不碰底层数据。只要 tensor.is_contiguous() 返回 True，view 就是零拷贝、纳秒级的。但一旦张量非连续（比如刚做过 transpose、permute 或切片），view 直接报错，根本不会进入执行阶段。
- 常见触发非连续的操作：
transpose()、permute()、narrow()、flip()、部分slice（如x[::2]） - 检查方式永远是：
x.is_contiguous()，别靠经验猜 - 连续张量上，
view(2, -1)和reshape(2, -1)实际调用的是同一段底层代码，性能完全一致
reshape 性能可能下降是因为它会隐式拷贝
reshape 的“智能”是有代价的：它内部先调 is_contiguous()，非连续时自动插入 contiguous() —— 而这个方法会分配新内存、复制全部数据。一次 reshape 可能变成一次 contiguous() + 一次 view()，开销从 O(1) 变成 O(N)。
- 典型慢场景：
x.transpose(0,1).reshape(-1, 1024)→ 先全量拷贝再 reshape - 拷贝不仅耗时，还增加显存压力，尤其在大 tensor（如图像 batch）上容易 OOM
- 用
torch.utils.benchmark.Timer测过：非连续时reshape比连续时慢 3–10 倍（取决于 tensor 大小）
什么时候真该用 reshape 而不是 view
不是“图省事就换 reshape”，而是明确需要它的行为：
- 你接收的是外部输入或中间层输出，无法保证连续性（如某些模型返回的
output.permute(1,0,2)） - 你正在写通用工具函数，要兼容各种上游操作，且不希望暴露底层连续性细节
- 你在处理标量（0 维张量）：
torch.tensor(42).reshape(1)合法，.view(1)报RuntimeError - 你后续不依赖内存共享（比如 reshape 后立刻 detach 或转 numpy），那隐式拷贝的影响可控
最容易被忽略的性能陷阱
很多人以为 “只要没报错，reshape 就安全”，但其实连续性状态是易变的，且 reshape 的拷贝行为完全静默 —— 它不警告、不日志、不抛异常，只悄悄变慢。
- 调试时用
print(x.storage().data_ptr())对比前后，能一眼看出是否发生拷贝 - 在训练循环关键路径（如 dataloader 输出后立即 reshape）里，宁可加一行
.contiguous()显式控制，也不要依赖reshape自动兜底 - PyTorch 2.0+ 中，
reshape在 JIT / TorchScript 下的行为更严格，非连续时可能直接失败而非拷贝
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
