1. 先把地基打牢：张量、设备、梯度这三件事
我带过几个刚入门深度学习的同学，几乎所有人第一次接触 PyTorch 的路径都一样：找个教程，抄一段训练循环，跑通一个分类任务，然后长舒一口气。可真让他改一行代码试试，问题就全冒出来了——形状对不上、梯度是 None、损失值横盘不动、显存莫名爆掉。这些问题在教程里一个都看不到，但它们才是真正决定你能不能把 PyTorch 用起来的东西。
所以这篇我不打算上来就堆模型，我想把"deep learning with pytorch"这个系列的第一篇，老老实实放在地基上：张量怎么用、设备怎么管、梯度是怎么自己算出来的。这三样东西贯穿你后面所有的代码，模型再复杂，底层跑的还是这三件事。如果你刚装好环境、手还生，或者已经抄过几段代码但总觉得心里没底，这篇应该能帮到你。我会把每一步为什么这么做讲清楚，也会把踩过的坑摆出来，方便你对照自己现在卡在哪个位置。
我个人的判断是，PyTorch 的学习曲线之所以看着平缓，是因为它把"计算图"这种东西藏起来了，你写 Python 它就执行 Python。这个特性是优点也是陷阱：优点是你调试的时候能直接 print，缺点是很多人永远不知道自己写的那行加法在背后悄悄建了一个节点。等哪天你需要冻结一部分参数、需要只推理不训练、需要自己写一个不太常规的损失函数，这些被藏起来的东西就会一次性找上门。先把它们摊开看一遍，后面省下来的时间远超你想象。
1.1 环境准备：版本对齐比装最新版重要得多
装环境这件事，我见过最多的问题不是装不上，是装上了版本互相打架。典型症状是代码跑到一半报某个符号找不到，或者明明装了加速版却一直用 CPU 在算。我的建议很朴素：先明确你的显卡驱动支持到哪个 CUDA 版本，再倒推着装对应版本的 PyTorch，别反着来。
具体操作上，我一般是这样走的：先用nvidia-smi看一眼驱动版本和它支持的最高 CUDA 版本，然后去 PyTorch 官网的安装命令生成器里选对应的组合，直接复制它给出的那行命令。这里有个小细节，很多人习惯用pip install torch，这条命令装下来的通常是预编译好的包，自带运行库，省事但也意味着包体积很大；如果你用 conda，注意 conda 的通道解析有时会把你已有的包降级，装完一定要验证。
验证的方式我写在下面，三行就够，别嫌麻烦，环境装错却以为装对了是最浪费时间的：
import torch print(torch.__version__) print(torch.cuda.is_available(), torch.cuda.device_count()) print(torch.randn(2, 3).to("cuda") if torch.cuda.is_available() else "无可用加速设备")最后一行如果报错，说明运行库和驱动没对上，这时候别急着改代码，回到环境层面解决。我吃过一次亏，花了两小时排查模型代码，结果是驱动版本太旧，换个环境十分钟搞定。从那以后我给自己定了个规矩：任何"莫名其妙"的报错，先花三十秒验证环境。
提示：如果你的机器没有独立显卡，完全没关系，这篇和后面几篇的示例都能在 CPU 上跑通，只是速度慢一些。学习阶段不建议为了跑通一个玩具模型去折腾驱动。
1.2 张量的三个属性，决定了你 90% 的报错
张量看着就是个多维数组，但它比 NumPy 的数组多带了两个关键信息：device和requires_grad。加上dtype，这三个属性构成了我排查问题的第一顺位检查项。几乎所有的"形状不匹配""设备不匹配""类型不匹配"，都能从这三项里找到答案。
shape的重要性不用多说，但我建议你养成一个习惯：写任何一行涉及张量运算的代码之前，先在脑子里过一遍输入和输出的形状。尤其是矩阵乘法，(N, C) @ (C, M)得到(N, M)，中间那个维度必须对上，这是硬约束。广播机制会在某些情况下帮你自动补齐维度，但也会在你写错的时候悄悄算出一个"看起来对"的结果，这是最危险的情况。
dtype这一项被低估得最厉害。默认的浮点类型是float32，而 Python 里的字面量默认是双精度，两者混在一起参与运算时，PyTorch 会做类型提升，结果是你的显存占用悄悄翻倍。更麻烦的是整型：标签、索引、掩码这些必须是int64，你从别的地方拿过来的数组如果是int32，在CrossEntropyLoss那里会直接报错。
x = torch.randn(4, 3) # float32，最常用 idx = torch.tensor([0, 2, 1]) # int64，注意不是 int32 mask = x > 0 # bool print(x.dtype, idx.dtype, mask.dtype)device是新手最容易翻车的一项。规则说穿了很简单：参与同一次运算的所有张量、以及模型本身，必须在同一个设备上。但实际操作中你会遇到"模型搬到 GPU 了，数据忘了搬""损失函数里手动造了一个新张量还在 CPU 上"这类问题。我的处理方式是写一个极短的工具函数，在训练开始前和每个 batch 里统一搬运，而不是到处散落.to(device)：
device = torch.device("cuda:0" if torch.cuda.is_available() else "cpu") def to_device(batch, device): if isinstance(batch, (list, tuple)): return [to_device(b, device) for b in batch] return batch.to(device, non_blocking=True)non_blocking=True配合锁页内存能稍微提升搬运效率，但对新手来说不加也行，别为了这点性能把逻辑搞乱。
注意：字符串形式的设备名
"cuda"和"cuda:0"在单卡机器上等价，但在多卡机器上行为不同。写"cuda"默认落到 0 号卡，如果你是想让代码在多卡环境下自适应，用torch.cuda.current_device()显式取值会更稳。
1.3 广播机制的直觉建立：把维度当尺子量一遍
广播是这个系列里我认为最值得花时间的一块。它的规则其实只有两条：从最后一维开始往前比，每一维要么相等，要么其中一个是 1，要么其中一个不存在；满足条件就扩展，不满足就报错。听起来绕，用起来很快，我的办法是"把形状写成两行，右对齐着看"。
举个常见的例子。假设你有一个(64, 10)的预测输出和一个(64,)的标签，你想算每个样本的某个加权项。直接相减会报错，因为(64, 10)和(64,)从后往前比，第一位 10 对 64 不等且没有 1，直接失败。正确写法是给标签补一个维度(64, 1)，这时候从后往前比，第一维 10 对 1 可以展开，第二维 64 对 64 相等，通过。
pred = torch.randn(64, 10) label = torch.randint(0, 10, (64,)) # 错误：pred - label -> 形状不兼容 loss_term = pred - label.unsqueeze(-1) # (64, 10)，正确这里我要说一个个人观点：广播写对了很简洁，写错了很难查，因为结果形状往往"看起来合理"。我的经验法则是，凡是涉及两个形状不同的张量的运算，只要不是一眼能看出来的标量运算，我都顺手加一行assert或者注释把形状写清楚。这不是啰嗦，这是在给三个月后的自己留后路。
1.4 视图、拷贝与内存：view 和 reshape 的区别要搞清楚
view和reshape都能改变形状，但前者要求底层内存是连续的，后者会在这条件不满足时悄悄拷贝一份。区别在哪？如果你的张量是permute或transpose之后的，内存已经不连续，view会直接抛错，而reshape会给你一份新内存的数据。这时候你改新数据，旧数据不会变，很多人因此写出"改了没生效"的诡异代码。
a = torch.randn(2, 3) b = a.t() # 转置，内存不连续 # b.view(6) # 报错 c = b.reshape(6) # 会拷贝，能跑 b[0, 0] = 100.0 print(c[0]) # 还是旧值，因为 c 是拷贝我一般的做法是：确定需要共享内存时用view，让错误暴露出来；只是想要个新形状、不在乎内存关系时用reshape，心里清楚这里可能有拷贝开销。至于clone和detach，前者拷贝数据，后者共享数据但切断计算图，这两个在后面的梯度部分还会再提。
2. 自动求导：让梯度自己算出来的代价与便利
自动求导是 PyTorch 最核心的能力，也是最容易被当成黑盒的部分。很多人知道要给张量设requires_grad=True，知道要调backward()，知道要zero_grad()，但这三件事各自的因果关系并不清楚，于是遇到"梯度为 None""梯度一直在累加""改了参数但不生效"的时候完全无从下手。
我想把这块讲透一点，因为它直接决定了你后面能不能写自定义损失、能不能做梯度裁剪、能不能冻结部分网络。这些操作在真实项目里全都是常规需求，而它们的本质都建立在同一个机制上：动态计算图。
2.1 计算图是在前向过程中顺手建起来的
PyTorch 采用动态图，意思是每次前向传播都会重新记录一遍运算过程。你写y = w * x + b，这一步不仅算出了数值，还在y上挂了一个grad_fn，指向产生它的那个加法操作，加法又指向乘法，乘法指向叶子张量w和b。这条链就是计算图。
w = torch.tensor(2.0, requires_grad=True) x = torch.tensor(3.0) y = w * x print(y.grad_fn) # MulBackward0 z = y + 1 print(z.grad_fn) # AddBackward0 z.backward() print(w.grad) # 3.0这里有个关键概念叫叶子张量。只有用户直接创建的张量（而不是运算结果）才是叶子，backward()之后梯度只会累积到叶子张量上。中间结果的梯度是临时保存的，除非你调用retain_grad()，否则用完就释放。这个设计是为了省内存，但也意味着你不能指望print(y.grad)能拿到东西。
我见过一个典型误用：某同学想在训练时观察中间层的梯度分布，一直打印出None，以为是梯度没传过去，其实是中间张量不是叶子。解决方式有两种，要么对想观察的张量调retain_grad()，要么用 hook 注册回调。第二种更灵活，后面讲模型结构的时候我会再用到。
注意：
backward()默认只对输出为标量的张量有效。如果输出是多维的，你必须传一个同形状的梯度参数进去，告诉它"每个位置的权重是多少"。绝大多数训练场景里我们会先聚合出一个标量损失，所以这条限制平时感知不到，但写自定义损失时很容易撞上。
2.2 梯度累加：为什么 zero_grad 是必须的，而不是可选的
这一点我想重点讲，因为它是新手最迷惑的地方。PyTorch 的梯度是累加的，不是覆盖的。也就是说，如果你调两次backward()而不清零，w.grad里存的是两次梯度之和。这个设计是有意为之的，它让"用多个小 batch 模拟一个大 batch"成为可能——累加几次梯度再step()一次，等价于更大 batch 的效果，对显存紧张的场景非常实用。
但如果你不知道这一点，就会写出"训练了十轮，损失几乎不动"的代码，因为梯度越加越大，参数一步就飞出去了。所以optimizer.zero_grad()在标准训练循环里是必需品，位置通常放在backward()之前：
for step in range(10): optimizer.zero_grad() # 清掉上一轮的梯度 out = model(x) loss = criterion(out, y) loss.backward() # 本轮梯度累加进来 optimizer.step() # 用完整梯度更新参数至于zero_grad()和optimizer.zero_grad(set_to_none=True)的区别，后者把梯度直接设成None而不是填零。新版 PyTorch 默认就是这个行为，好处是省掉一次全量写内存，还能让某些优化器跳过没有梯度的参数。如果你在旧代码里看到zero_grad()不带参数，不用奇怪，行为上有细微差别但不影响正确性。
顺带说一个梯度累加的实际用法。假设单卡显存只够跑 batch size 8，但你想获得 batch size 32 的效果，可以这样写：
accum_steps = 4 optimizer.zero_grad() for i, batch in enumerate(loader): out = model(batch["x"]) loss = criterion(out, batch["y"]) / accum_steps # 别忘了除 loss.backward() if (i + 1) % accum_steps == 0: optimizer.step() optimizer.zero_grad()那个除法很容易漏，漏了就等于把所有 loss 加起来，梯度是正常值的 4 倍，学习效果直接崩掉。这一点我建议你在代码里特意写一行注释，别依赖记忆。
2.3 detach、no_grad 与推理模式：三者的边界在哪里
这三个东西都跟"不要建图"有关，但用错了会带来完全不同的后果，值得单独拎出来说。
detach()是作用在张量上的，返回一个共享数据但脱离计算图的新张量。它最典型的用途是两处：一是把损失值拿出来记日志，避免日志对象持有整个计算图造成内存泄漏；二是强化学习或对抗训练里，你希望某一部分的梯度不要回传到另一部分。
torch.no_grad()是作用在代码块上的，块内所有运算都不记录梯度。验证和推理时用它，能显著降低显存占用。注意它不能嵌套出"重新开启梯度"的效果，如果你在no_grad块里需要临时建图，得用torch.enable_grad()。
torch.inference_mode()是更激进的版本，除了不建图，还会把张量标记成推理张量，禁止后续被用于需要梯度的运算，并且有额外的性能优化。我在纯推理脚本里一律用它，训练代码里则用no_grad。
model.eval() with torch.inference_mode(): for batch in val_loader: logits = model(to_device(batch["x"], device)) preds = logits.argmax(dim=1)有个小坑要提醒：验证时忘了写model.eval()，某些层（比如批归一化和随机失活）的行为会和训练时不一致，导致验证指标诡异波动。我排查过一次线上"验证集准确率忽高忽低"，最后发现是漏了这三行中的一行。现在我的习惯是把model.train()和model.eval()分别写进训练和验证函数的开头，不依赖外部调用，从结构上杜绝遗忘。
3. 从零搭一个能跑通的训练流程
把上面的地基铺好之后，就可以动手搭一个完整的训练流程了。我选一个结构简单但五脏俱全的任务：小尺寸图像的多分类。这个任务的好处是数据量小、模型小、CPU 上也能跑完，但训练循环里该有的东西一样都不少——数据加载、模型定义、损失计算、反向传播、指标统计、验证评估。
我想强调一点：这一节的重点不是任务本身，而是那套结构。你可以把这里的图像换成文本、换成表格、换成时序信号，训练循环的骨架几乎不用改。把这套骨架跑熟、跑顺手，比跑通一百个不同任务的 demo 有用得多。
3.1 数据集与加载器：先搞清楚数据的形状和取值范围
数据加载这块，我建议你养成先探查再建模的习惯。拿到一份数据，先回答四个问题：单条样本的形状是什么？数值范围是多少？标签的编码方式是什么？有没有类别不均衡？这四个答案直接决定了模型第一层的输入维度、需不需要归一化、损失函数选哪个、要不要加重采样。
sample = dataset[0] print(type(sample), len(sample)) print(sample[0].shape, sample[0].dtype, sample[0].min(), sample[0].max()) print(sample[1], type(sample[1]))数值范围这一项经常被忽略。原始像素通常在 0 到 255 之间，如果不做归一化就直接送进网络，第一层的激活值会非常大，梯度也跟着大，配合稍大一点的学习率就是一场灾难——损失直接变成nan。标准做法是缩放到 0 到 1，再做标准化：
from torchvision import transforms transform = transforms.Compose([ transforms.ToTensor(), # 自动缩放到 [0,1]，并把通道提到前面 transforms.Normalize(mean=[0.5], std=[0.5]), # 变成 [-1,1] 附近 ])这里ToTensor()有个容易被忽视的副作用：它会把H x W x C变成C x H x W。如果你自己写数据读取，忘了这一步，模型第一层就会拿到形状不对的输入。
DataLoader的配置里，batch_size、shuffle、num_workers是最常调的三个。训练集要shuffle=True，验证集设为False；num_workers在 Linux 下可以设成 CPU 核数的四分之一左右，Windows 下建议先设 0 跑通再往上加，因为多进程启动方式不同，容易出一些奇怪的报错。
提示：
DataLoader的pin_memory=True只在有加速设备且数据搬运频繁时有收益，CPU 训练时设了没有意义，反而多占一份锁页内存。
3.2 模型定义：从 nn.Module 的三件套开始
定义模型这件事，我一般要求自己至少理解三样东西：__init__里注册了哪些子模块、forward里数据怎么流动、参数量大概是多少。前两样决定了代码怎么写，第三样决定了显存够不够、要不要简化。
import torch.nn as nn class SmallNet(nn.Module): def __init__(self, in_dim=784, hidden=256, num_classes=10): super().__init__() self.net = nn.Sequential( nn.Linear(in_dim, hidden), nn.ReLU(inplace=True), nn.Dropout(0.2), nn.Linear(hidden, num_classes), ) def forward(self, x): return self.net(x)这里super().__init__()必须最先调用，否则子模块注册不上，parameters()会返回空，优化器拿不到东西，训练时你会看到"损失完全不动"这种最让人抓狂的现象。我遇到过一次，排查了半天才想起来是构造函数里少了这一行。
参数量的估算很简单，全连接层的参数量是输入维度 × 输出维度 + 输出维度。上面这个模型是784×256+256 + 256×10+10 = 203,530个参数。这个数字有什么用？一是心里有数，二是可以反推显存。参数本身按float32算大约 0.8MB，但训练时每个参数还要额外存一份梯度、优化器状态（Adam 要存两份），所以实际占用是参数量的四倍左右。再加上前向过程中保存的中间激活值，显存需求通常是参数量的五到十倍。
如果换成卷积层，输出尺寸的计算公式是(H - K + 2P) / S + 1，这个式子我建议你记牢，定义卷积时顺手算一遍，能省掉大量形状不匹配的报错。举个例子，输入 28×28，卷积核 3×3，步长 1，填充 1，输出还是 28×28；如果步长改成 2，输出就是 14×14。步长为 2 的卷积和池化效果接近，但前者能学习、后者不能，这是我更倾向用步长卷积做下采样的原因。
3.3 损失函数与优化器：选型背后的逻辑
损失函数的选型，核心看两件事：任务类型和标签形态。多分类、单标签，用交叉熵；多分类、多标签，用带 sigmoid 的二元交叉熵；回归用均方误差或平滑版；类别极不均衡时考虑带权重的版本。
这里有个新手最常踩的坑：交叉熵损失内部已经包含了 softmax，所以模型的最后一层不能再加 softmax。加了会怎样？不会报错，但概率分布会被压缩两次，梯度变小，收敛变慢，而且你算出来的概率数值看着还挺"像那么回事"，很难发现。我的习惯是模型输出一律叫logits，命名上就提醒自己这里没做归一化。
criterion = nn.CrossEntropyLoss() # 模型 forward 输出 logits，不要在模型里加 softmax logits = model(x) loss = criterion(logits, target) # target 是 int64，形状 (N,)优化器方面，SGD 加动量是经典配置，收敛稳但慢；Adam 系列上手快、对学习率不敏感，但泛化有时略逊。我在做快速验证和原型时首选 Adam，确定方向之后再回来试 SGD 调参。学习率的默认值，Adam 用 1e-3 是个不错的起点，SGD 通常从 1e-2 配 0.9 动量开始。
还有一个经常被问到的问题：batch size 变了，学习率要不要跟着变？我的经验是要，但不是简单线性。小 batch 时梯度噪声大，学习率要小一些；大 batch 时梯度更稳，可以适当放大。经验公式是学习率正比于 batch size 的平方根，比线性缩放保守一些，实测更稳。当然更可靠的做法是配一个简单的学习率预热，前几百步从很小的值线性升上去。
3.4 完整训练循环：把每一步的意图写清楚
下面这个循环是我自己常用的模板，结构上分训练和验证两段，指标统计用累加的方式，避免把所有预测存下来占内存。
def train_one_epoch(model, loader, criterion, optimizer, device): model.train() total_loss, total_correct, total_num = 0.0, 0, 0 for batch in loader: x = to_device(batch[0], device) y = to_device(batch[1], device) optimizer.zero_grad() logits = model(x) loss = criterion(logits, y) loss.backward() optimizer.step() total_loss += loss.item() * y.size(0) total_correct += (logits.argmax(dim=1) == y).sum().item() total_num += y.size(0) return total_loss / total_num, total_correct / total_num @torch.no_grad() def evaluate(model, loader, criterion, device): model.eval() total_loss, total_correct, total_num = 0.0, 0, 0 for batch in loader: x = to_device(batch[0], device) y = to_device(batch[1], device) logits = model(x) loss = criterion(logits, y) total_loss += loss.item() * y.size(0) total_correct += (logits.argmax(dim=1) == y).sum().item() total_num += y.size(0) return total_loss / total_num, total_correct / total_num这份代码里有几个细节值得单独说。loss.item()这一句不是可有可无的：如果不加.item()而是直接把张量累加进 Python 变量，你实际上每步都在往列表里塞一个带计算图的张量，显存会随着训练步数稳步上涨，跑一会儿就爆。这是我在实际项目里见过最多的内存泄漏原因，没有之一。
损失按样本数加权平均，而不是按 batch 数取平均。如果最后一个 batch 不满，按 batch 平均会让结果有偏差，虽然数值上差别不大，但统计口径不对的话，跨配置比较时会误导判断。
准确率的统计用argmax(dim=1)，注意那个dim=1，它对应的是类别维度。写错维度是另一个高频错误，尤其当你的张量维度顺序和习惯不一样时，argmax会在错误的位置取最大值而不报错，结果就是准确率一直在随机水平附近晃。
3.5 训练过程中的观察指标：别只盯着损失
只盯损失值和准确率，会漏掉很多信息。我一般在训练开始前先跑一次"随机初始化基线"，看看模型在没学任何东西时的表现，比如十类分类大概是 10% 左右。这个数字看着废话，但它能帮你快速区分"模型没学到东西"和"评估代码写错了"——如果准确率稳定在 0%，多半是评估逻辑有 bug，不是模型的问题。
另外我会记录每轮的学习率和梯度范数。学习率曲线能看出调度器有没有生效，梯度范数能看出训练是否稳定。梯度范数突然从个位数涨到三位数，通常意味着某一步遇到了异常样本或者学习率太大，这时候上梯度裁剪能救回来。
total_norm = 0.0 for p in model.parameters(): if p.grad is not None: total_norm += p.grad.detach().norm(2).item() ** 2 total_norm = total_norm ** 0.5 torch.nn.utils.clip_grad_norm_(model.parameters(), max_norm=5.0)裁剪阈值设成多少合适？没有普适答案，我一般从 1.0 到 5.0 之间试，看梯度范数的分布决定。设得太小会让训练变慢甚至停滞，设得太大等于没裁。判断标准很简单：裁剪之后，正常情况下被裁剪的步数应该占比很低，如果大部分步都被裁，说明阈值不合适或者学习率太大了。
4. 常见问题与排查实录
这一节是我认为整篇最值钱的部分，因为上面那些内容你在任何一份文档里都能找到，而下面这些是我自己一次次踩出来的。
4.1 损失变成 nan：按这个顺序查
损失变nan是最常见的崩溃方式，排查顺序我固定成四步。第一步查学习率，把它降到原来的十分之一再跑几百步，如果正常了就是学习率问题。第二步查输入，打印一个 batch 的min/max/mean，看有没有异常值、有没有全零、有没有inf。第三步查损失函数内部，特别是自己写的部分，有没有log(0)、有没有除以零、有没有对负数开方。第四步查梯度，用前面的范数统计看是哪一层先炸的。
自写损失里log是最容易出事的。交叉熵里面有个log(p)，当p被压到 0 时结果就是负无穷。标准实现里会做数值稳定处理，你自己实现时得加一个极小值：
eps = 1e-8 loss = -(y * torch.log(p + eps)).sum(dim=1).mean()混合精度训练也会引入nan，因为float16的表示范围太窄，梯度小到一定程度就下溢成 0，大到一定程度就溢出成inf。解决办法是用带动态缩放的版本，它会自动调整缩放系数。
4.2 显存不够：先判断是哪种不够
显存报错分两种：一种是启动就爆，一种是跑着跑着慢慢涨。前者好办，减小 batch size、减小模型、缩短序列长度，三个里挑一个。后者才是真麻烦，说明有东西在累积。
跑着跑着涨的典型原因有三个。第一个是前面说的，忘了.item()，把带计算图的张量存进了列表。第二个是在验证阶段忘了no_grad，每轮都在建图。第三个是把每步的输出都存进了一个不断增长的列表，比如把每个 batch 的预测拼起来之后一直留着。
排查方式很直接，在训练循环里每隔几十步打印一次显存占用，看它是不是单调上升。如果是，再在可疑位置逐段注释掉，二分定位。这个方法笨，但最快。
| 现象 | 可能原因 | 处理方式 |
|---|---|---|
| 启动即显存不足 | batch size 或模型过大 | 减半 batch size，先跑通再调 |
| 显存随步数缓慢上涨 | 张量累积未释放 | 检查.item()、no_grad、列表累积 |
| 验证阶段比训练阶段更吃显存 | 未关闭梯度 | 加@torch.no_grad()装饰器 |
| 换更大输入尺寸后爆显存 | 激活值占用随尺寸平方增长 | 降低分辨率或改用步长卷积提前降采样 |
4.3 高频报错速查
下面这张表是我自己整理的高频报错对照，覆盖了入门阶段八成的报错场景。
| 报错关键词 | 根因 | 快速修复 |
|---|---|---|
size mismatch | 全连接层输入维度和特征维度不一致 | 打印x.shape后逐层核对，卷积后接全连接前要flatten |
Expected all tensors to be on the same device | 模型和数据不在同一设备 | 统一搬运，检查损失函数内部新建的张量 |
element 0 of tensors does not require grad | 优化器里的参数没有梯度，通常是没调backward或参数没注册 | 检查parameters()是否为空 |
Target x is out of bounds | 标签里有超出类别数的值 | 检查标签范围，注意 0 基索引 |
view size is not compatible | 内存不连续或形状计算错误 | 改用reshape，或先contiguous() |
CUDA out of memory | 显存不足 | 降 batch size，检查是否有累积 |
表里第三行特别值得说。does not require grad这个报错表面上在说梯度，实际原因往往是优化器拿到的是一个空列表或者一批不需要梯度的张量。我遇到过的情形是把模型包在了一个普通 Python 列表里传给优化器，parameters()返回空，优化器什么都管，step()什么也不做。
4.4 三个容易被忽略的实操心得
第一个心得：任何新写的训练脚本，先在一个 batch 上过拟合。把数据缩到只有几个样本，关掉正则化，训练几百步，损失应该能降到接近 0。这一步能排除掉数据管道、标签对应、损失函数这几块的绝大多数问题。如果几个样本都拟合不了，模型再大也没用。
第二个心得：随机种子固定要一次到位，不只是torch.manual_seed，还要管住 NumPy 和数据加载器的 worker。少设一个，复现结果就对不上，然后你会花大量时间去怀疑模型，而问题其实在随机性。
import random, numpy as np, torch def set_seed(seed=42): random.seed(seed) np.random.seed(seed) torch.manual_seed(seed) torch.cuda.manual_seed_all(seed)第三个心得：日志里一定要带步数和轮次。我见过太多人拿着一张没有横轴刻度的损失曲线来分析，最后连"从第几步开始崩的"都说不清。日志格式我一般用epoch/step | loss | acc | lr | grad_norm这几项，够用且不啰嗦。
5. 我个人在入门阶段的几点体会
写到这里，我想说点不那么技术的东西。刚接触 PyTorch 的时候，我也曾经执着于"把模型搭出来"，觉得数据处理、循环写法这些都是杂活，能跑就行。结果就是每次换个任务都要重写一遍，而且每次都在同样的地方犯错。真正让我效率提上来的，是把训练循环、数据探查、日志记录这几块写成了自己顺手的模板，用的时候直接改形状和超参。
另一个体会是关于调试节奏。深度学习的调试和普通软件开发不一样，很多问题不会报错，只会表现为"效果差一点"。这种时候最忌讳的是同时改好几个东西然后看结果。我的做法是一次只动一个变量，并且把改动和对应的指标变化记下来。听起来很笨，但两个月之后回头看，这些记录比任何教程都有用，因为它们是针对你自己的代码和数据集的。
最后一点，关于要不要从零手写。我的建议是前两三个任务老老实实手写循环，把每一步的因果搞清楚；之后再上高层封装提效。反过来先学封装的话，遇到问题你连该看哪一层都不知道。这篇讲的所有内容，本质上都是在帮你建立这个"知道该看哪一层"的直觉。
