view()要求张量内存连续，否则报RuntimeError；transpose等操作会破坏连续性，需contiguous()显式复制内存；reshape()更安全，自动处理连续性；非连续张量还会影响GPU性能。
不加 contiguous()，很多 reshape 和 view 操作会直接报错，不是语法问题，而是内存布局不满足底层要求。
view() 报错：RuntimeError: view cannot be called on a tensor that is not contiguous
这是最常见、最典型的触发场景。PyTorch 的 view() 函数要求输入张量的内存必须是连续的，否则拒绝执行。
常见诱因包括：
-
transpose()或permute()后立即调用view() -
narrow()、expand()、切片如x[:, 1]等共享 storage 的操作 - 从某些 DataLoader 返回的 batch 张量（尤其经过 pad 或 mask 处理后）
示例：
立即学习“Python免费学习笔记（深入）”；
import torch x = torch.randn(2, 3, 4) y = x.permute(1, 0, 2) # shape=(3,2,4)，但 y.is_contiguous() == False z = y.view(3, -1) # ⚠️ RuntimeError
修复只需加一步：y.contiguous().view(3, -1)。
contiguous() 不是“修复”，而是显式申请一次内存复制
contiguous() 并不会原地整理内存，而是创建一个新张量，把数据按行优先顺序重新拷贝进一块新分配的连续内存中。这意味着：
- 调用后
.data_ptr()一定和原张量不同 - 会带来额外内存开销和拷贝时间，尤其在 GPU 上可能触发 host-device 同步
- 如果后续操作不需要
view()或matmul()等强连续性依赖，其实可以跳过
对比替代方案：reshape() 在内部会自动检查连续性，等价于 contiguous().view()，但它更“懒”——仅当必要时才复制。所以多数情况下，用 reshape() 比手动 contiguous().view() 更安全省心。
GPU 训练中隐性性能陷阱：非连续张量拖慢 kernel 执行
即使没报错，非连续张量也可能让模型变慢。原因在于：
- CUDA kernel 对连续内存访问有高度优化；非连续张量导致内存读取跳跃，缓存命中率骤降
- 某些算子（如
torch.nn.functional.linear）内部会悄悄调用contiguous()，但这个过程发生在 kernel 启动前，无法被 profile 工具直观捕获 - 在混合精度训练中，非连续输入还可能干扰
amp.autocast的 memory layout 推断
排查建议：
- 在关键路径（如 attention 中 QKV reshape）前后插入
assert x.is_contiguous() - 用
torch.cuda.memory_summary()观察是否有异常增长——可能是隐式contiguous()在反复分配 - 对固定结构的模型，可提前在
__init__或forward开头统一做一次contiguous()，避免分散调用
真正容易被忽略的是：连续性不是“永久属性”，它只在某个操作节点上成立。一次 transpose() 就能把它打破，而你可能在十几行代码之后才调用 view() ——中间没有任何提示。所以与其靠记忆判断，不如养成习惯：只要做过维度重排，下一步要 reshape 或传给某层，就先过一遍 .contiguous() 或改用 .reshape()。
