view要求张量连续，否则报错；reshape自动处理连续性但可能隐式拷贝。明确连续时用view，不确定时用reshape，需警惕性能与内存开销。
view 要求张量必须连续，否则直接报错
当你调用 view 时，PyTorch 不做任何内存调整，只尝试基于当前 stride 和 storage 生成新 shape 的视图。如果张量不连续（比如刚做过 transpose、permute 或某些切片），view 就会抛出 RuntimeError: view size is not compatible with input tensor's size and stride。
常见触发场景：
-
x.t().view(-1)—— 转置后几乎总是非连续 -
x[:, ::2].view(-1, 4)—— 步长被破坏的切片 -
x.narrow(0, 0, 2).view(2, -1)—— 非连续子视图
这时不能靠“猜”，得先用 x.is_contiguous() 确认；若为 False，必须显式加 .contiguous() 才能继续用 view。
reshape 自动适配连续性，但可能隐式拷贝
reshape 的行为是条件分支：输入连续 → 返回共享内存的视图（等价于 view）；输入非连续 → 先调用 .contiguous() 触发数据复制，再 view。这意味着它总能成功，但代价不透明。
立即学习“Python免费学习笔记（深入）”；
关键影响：
- 性能：对大张量反复
reshape非连续输入，会频繁分配新内存、拷贝数据，拖慢训练 - 内存：拷贝后的新张量与原张量不再共享
data_ptr() - 调试困难：你无法从代码表面判断是否发生了拷贝
示例：x.t().reshape(-1) 看似简洁，实则暗含一次完整内存复制。
何时该用 view，何时选 reshape
没有银弹，取决于你对张量状态的掌控程度：
- 明确知道张量连续（如刚创建、或刚调过
.contiguous()）→ 优先用view，零开销、语义清晰 - 不确定连续性，且不关心底层是否拷贝 → 用
reshape，省心但需警惕性能隐患 - 需要保证内存共享（比如后续要原地修改并影响上游）→ 只能用
view，且必须确保连续 - 处理标量或 0 维张量 →
reshape支持（如torch.tensor(42).reshape(1)），view会报错
检查和修复非连续张量的惯用写法
别等到报错才处理。日常编码中建议养成主动检查的习惯：
快速验证：print(x.is_contiguous(), x.stride()) —— 连续张量的 stride 应满足行优先递减规律（如 shape=(3,4) 对应 stride=(4,1)）。
安全转换模式：
- 想保留
view的轻量性？写成x.contiguous().view(new_shape) - 想避免意外拷贝？在 pipeline 前段就插入
.contiguous()，比如x = x.transpose(0,1).contiguous() - 批量操作前统一规整：
batch = batch.contiguous() if not batch.is_contiguous() else batch
最易被忽略的是：非连续张量在 GPU 上也可能引发隐式同步或内核降级，不光是 CPU 内存问题。
