企业官网建设流程全解析

1. 从一行import开始：为什么PyTorch成了我手里最顺手的工具

如果你问我现在做深度学习项目首选什么框架，我会毫不犹豫地说PyTorch。这不是盲目跟风，而是这些年一个个项目实打实跑下来形成的习惯。很多刚入门的朋友经常问我：TensorFlow和PyTorch到底选哪个？我的回答通常是——先别纠结，把PyTorch跑通一遍，你自然就有判断了。

PyTorch本质上是一个基于动态计算图的深度学习框架。说人话就是：你写代码的时候，计算过程是实时构建的，就像用Python写普通程序一样自然，而不是先定义一个静态的图再往里灌数据。这个特性带来的最大好处就是调试极其方便——你可以在任意一行代码打断点，用print看张量的值，用pdb单步跟踪，跟调试普通Python脚本没有任何区别。

我最初从其他静态图框架转过来的时候，最直观的感受就是：终于不用在脑子里模拟整个计算流程了。以前调一个自定义层，得先想清楚输入输出的维度怎么对齐、图怎么连，然后祈祷编译能过。换成PyTorch之后，直接写forward函数，跑一遍看shape对不对，不对就改，整个过程行云流水。

这篇文章我打算从实际使用的角度，把PyTorch的核心机制、环境搭建、张量操作、模型构建、训练流程、性能调优和踩坑经验完整地梳理一遍。不管你是刚接触深度学习的新手，还是从其他框架迁移过来的老手，应该都能从中找到对自己有用的东西。我不会照本宣科地翻译官方文档，而是把我在真实项目里积累的经验和教训分享出来，让你少走弯路。

2. 动态图到底意味着什么：PyTorch的核心机制拆解

2.1 动态计算图与静态计算图的本质差异

要理解PyTorch为什么好用，得先搞清楚动态图和静态图的区别。静态图的工作方式是"先定义、后运行"——你先声明好整个计算流程，框架把它编译成一张固定的图，然后你再把数据喂进去执行。动态图则是"边定义、边运行"——每执行一行代码，计算图就实时构建出来，执行完立刻得到结果。

打个比方：静态图就像你先画好一张完整的电路图，然后通电测试；动态图则是你边接线边通电，每接一根线就能看到效果。前者适合大规模部署和优化，后者适合快速迭代和调试。

这个差异在实际开发中影响巨大。我做过一个序列标注的项目，输入长度是变化的，每个batch里的样本长度都不一样。用静态图框架的时候，我得把所有输入padding到统一长度，或者写复杂的循环逻辑来处理变长序列。换成PyTorch之后，直接在forward里写循环就行，每个时间步的计算图是动态生成的，天然支持变长输入。

2.2 autograd的工作原理解析

PyTorch的自动求导机制autograd是整套体系的核心。它的工作逻辑其实不复杂：每个张量都有一个requires_grad属性，当你对一个requires_grad=True的张量做运算时，PyTorch会在后台记录这个运算，构建一张有向无环图。当你调用.backward()的时候，它沿着这张图反向传播，自动计算每个叶子节点的梯度。

这里有个关键细节很多人容易忽略：梯度是累加的，不是替换的。也就是说，如果你在训练循环里忘了调用optimizer.zero_grad()，梯度会在每次backward之后不断累加，导致参数更新完全错误。我见过不止一个新手因为这个原因训练出来的模型loss不降反升，排查半天才发现是忘了清梯度。

另一个值得注意的点是torch.no_grad()的使用。在推理阶段或者评估阶段，你不需要计算梯度，这时候用with torch.no_grad():包裹起来，可以显著减少内存占用和计算量。我实测过一个ResNet-50的推理任务，加上no_grad之后显存占用直接降了将近40%，速度也有明显提升。

2.3 计算图的释放时机与内存管理

动态图的一个副作用是：每次前向传播都会构建一张新的计算图，如果你不及时释放，内存会迅速膨胀。PyTorch的设计是：每次调用.backward()之后，计算图的中间缓存会被释放（除非你指定retain_graph=True）。但前向传播过程中产生的中间变量，如果被Python变量引用着，就不会被回收。

这就引出了一个常见的显存泄漏场景：你在训练循环里把loss或者中间结果存到了一个列表里，想着后面画曲线用。结果这些张量一直持有计算图的引用，显存越用越多，最后OOM。正确的做法是存loss.item()，只保留数值，不保留张量本身。

我在一个图像分割项目里就踩过这个坑。当时为了记录每个epoch的dice系数，把预测结果直接append到了一个列表里，跑了几十个epoch之后显存爆了。后来改成只存标量值，问题立刻解决。这个经验告诉我：在训练循环里，任何需要跨迭代保存的数据，都要先detach()或者转成Python标量。

3. 环境搭建：从零开始把PyTorch跑起来

3.1 版本选择与安装方式对比

PyTorch的安装方式主要有conda和pip两种，我的建议是优先用conda。原因很简单：conda能自动处理CUDA和cuDNN的依赖关系，省去了手动配置环境变量的麻烦。pip安装的话，你需要自己确保系统里的CUDA版本和PyTorch编译时用的版本匹配，否则会出现各种奇怪的错误。

版本选择上，我一般遵循两个原则：第一，不追最新版，选稳定版；第二，CUDA版本要和显卡驱动兼容。具体来说，你可以用nvidia-smi命令查看驱动支持的CUDA版本，然后去PyTorch官网找到对应的安装命令。比如驱动支持CUDA 11.8，那就装cu118版本的PyTorch。

这里有个细节：PyTorch官网的安装命令生成器会给你一条完整的conda install命令，直接复制执行就行。但要注意，如果你在国内网络环境下，可能需要配置镜像源加速下载。我通常用清华源或者中科大的源，速度会快很多。

3.2 验证安装是否成功的关键检查点

装完之后别急着跑模型，先做几个基本检查。第一步，进入Python环境，执行import torch，看有没有报错。第二步，打印torch.__version__确认版本号。第三步，执行torch.cuda.is_available()，返回True说明GPU可用。第四步，创建一个张量放到GPU上，做一次简单的矩阵乘法，确认计算正常。

我遇到过一种情况：torch.cuda.is_available()返回True，但实际跑模型的时候报CUDA error。后来发现是CUDA版本和驱动不匹配，虽然能识别到显卡，但实际计算时会出错。所以第四步的实测运算很重要，不能只看is_available的结果。

还有一个容易被忽略的点：多卡环境下的设备可见性。如果你服务器上有8张卡，但只想用其中2张，可以在代码开头设置os.environ['CUDA_VISIBLE_DEVICES'] = '0,1'。注意这行代码必须放在import torch之前，否则不生效。我有一次调了半天发现模型还是跑在所有卡上，就是因为import顺序搞反了。

3.3 虚拟环境管理的实操建议

我强烈建议每个项目单独建一个conda虚拟环境。原因很实际：不同项目可能依赖不同版本的PyTorch或者不同的第三方库，混在一起迟早出冲突。创建环境的命令很简单：conda create -n project_name python=3.9，然后conda activate project_name激活。

环境命名上，我习惯用项目名加日期的方式，比如seg_project_2024，这样一眼就能看出是哪个项目、什么时候建的。另外，养成导出环境依赖的习惯：conda env export > environment.yml，换机器的时候直接conda env create -f environment.yml就能复现整个环境。

还有一个小技巧：在虚拟环境里装包的时候，尽量用conda install而不是pip install，除非conda源里没有这个包。因为conda能更好地管理二进制依赖，减少版本冲突的概率。如果非要用pip，记得先conda install pip，确保pip装在这个环境里而不是全局。

4. 张量操作：PyTorch的地基怎么打才稳

4.1 张量创建与设备迁移的常见误区

张量是PyTorch里最基本的数据结构，你可以把它理解成多维数组，但比numpy的ndarray多了GPU加速和自动求导的能力。创建张量的方式有很多种：torch.tensor()从Python列表创建，torch.zeros()创建全零张量，torch.randn()创建随机张量，torch.from_numpy()从numpy数组转换。

设备迁移是新手最容易出错的地方。PyTorch不会自动把数据搬到GPU上，你需要显式地调用.to(device)或者.cuda()。常见错误是：模型搬到GPU了，但输入数据还在CPU上，一跑就报错。我的习惯是在代码开头定义device = torch.device('cuda' if torch.cuda.is_available() else 'cpu')，然后模型和数据都统一用.to(device)。

还有一个性能相关的细节：频繁地在CPU和GPU之间搬运数据是很慢的。我见过有人在训练循环里每一步都把loss搬到CPU上打印，结果训练速度慢了一半。正确的做法是累积一段时间再统一搬运，或者直接用.item()只取数值。

4.2 维度变换与广播机制的实际应用

维度变换是深度学习中最高频的操作之一。view()、reshape()、permute()、transpose()这几个函数长得像但用法不同。view()要求张量在内存里是连续的，reshape()则更灵活，必要时会复制一份数据。permute()可以任意交换维度顺序，transpose()只能交换两个维度。

广播机制是另一个必须掌握的概念。当两个形状不同的张量做运算时，PyTorch会自动扩展维度较小的那个。比如一个形状为(3, 1)的张量和一个形状为(1, 4)的张量相加，结果形状是(3, 4)。这个机制能省去很多手动扩展维度的代码，但也容易引入隐蔽的bug。

我有一次做注意力机制的时候，query和key的形状分别是(batch, heads, seq_len, dim)和(batch, heads, dim, seq_len)，直接做矩阵乘法得到(batch, heads, seq_len, seq_len)的注意力权重。当时没注意广播的问题，结果seq_len维度对不上，排查了好久才发现是转置的时候搞错了维度顺序。建议每次做完维度变换后，都打印一下shape确认。

4.3 原地操作与内存复用的性能权衡

PyTorch里很多操作都有原地版本，比如add_()、mul_()、relu_()，带下划线的就是原地操作，会直接修改原张量而不创建新的。原地操作能节省内存，但在自动求导的场景下要小心使用，因为它可能破坏计算图的正确性。

我的经验是：在前向传播中尽量避免原地操作，除非你很清楚自己在做什么。在不需要梯度的场景下（比如数据预处理），可以放心用原地操作来省内存。另外，ReLU的原地版本relu_()在模型里用得很普遍，因为ReLU本身不改变张量的形状，原地操作是安全的。

还有一个内存相关的技巧：如果你需要频繁创建和销毁同样形状的张量，可以考虑用torch.empty()预分配一块内存，然后用copy_()或者fill_()来填充数据。这在自定义训练循环里能减少内存分配的开销，对性能有一定提升。

5. 模型构建：从nn.Module到自定义层的完整路径

5.1 nn.Module的设计哲学与继承规范

PyTorch构建模型的标准方式是继承nn.Module。这个类做了很多事情：它帮你管理参数、支持GPU迁移、提供了train()和eval()模式切换、处理了hook机制等等。你只需要做两件事：在__init__里定义子模块，在forward里定义计算流程。

这里有个新手常犯的错误：在forward里动态创建层。比如有人写self.linear = nn.Linear(10, 10)放在forward里面，每次前向传播都新建一个层，参数完全不共享，模型根本学不到东西。正确的做法是在__init__里定义好所有层，forward里只做计算。

另一个细节是：nn.Module的__call__方法会调用forward，但中间还会处理一些hook逻辑。所以调用模型的时候用model(x)而不是model.forward(x)，后者会跳过hook，可能导致一些功能失效。

5.2 参数初始化策略对训练收敛的影响

参数初始化看起来是个小问题，但对训练收敛的影响非常大。PyTorch默认的初始化是Kaiming均匀分布，对ReLU激活函数来说是个不错的选择。但如果你用的是Sigmoid或者Tanh，默认初始化可能就不太合适了，容易导致梯度消失。

我一般会根据激活函数来选择初始化方法：ReLU系列用Kaiming初始化，Sigmoid/Tanh用Xavier初始化。具体实现可以用nn.init模块里的函数，比如nn.init.kaiming_normal_(layer.weight, mode='fan_out', nonlinearity='relu')。

还有一个经验：最后一层的初始化要特别注意。比如分类任务的最后一层，如果初始化得不好，初始loss会很大，训练前期会浪费很多时间在调整上。我通常会把最后一层的权重初始化得小一点，偏置设为零，这样初始预测接近均匀分布，训练更稳定。

5.3 自定义层的实现要点与调试技巧

有时候内置的层满足不了需求，需要自己写。自定义层的关键是继承nn.Module，在__init__里定义可学习参数（用nn.Parameter包装），在forward里实现计算逻辑。如果这个层有可学习的参数，记得用nn.Parameter包装，否则不会被优化器识别。

调试自定义层的时候，我有个习惯：先写一个最简单的输入，手动算一遍期望输出，然后跑代码对比。如果对不上，就在forward里加print，逐步定位问题。另外，可以用torch.autograd.gradcheck来验证自定义的backward是否正确，虽然麻烦一点，但能避免很多隐蔽的错误。

我还想强调一点：自定义层里尽量不要用Python的控制流来改变计算图的结构，除非你确实需要动态图特性。因为这样会导致每次前向传播的计算图都不一样，影响性能优化。如果确实需要条件分支，考虑用torch.where()或者mask机制来实现。

6. 训练流程：把模型跑起来只是第一步

6.1 DataLoader的配置陷阱与性能调优

DataLoader是PyTorch数据加载的核心组件，用好了能大幅提升训练效率，用不好就是性能瓶颈。几个关键参数：batch_size控制每批数据量，shuffle决定是否打乱顺序，num_workers指定加载数据的进程数，pin_memory决定是否把数据锁在内存里加速GPU传输。

num_workers的设置有个经验法则：设为CPU核心数的一半到两倍之间。设太小了数据加载跟不上GPU计算，设太大了进程间通信开销反而拖慢速度。我一般从4开始试，根据GPU利用率和数据加载时间调整。pin_memory=True在GPU训练时几乎总是有益的，能让数据从CPU到GPU的传输更快。

还有一个容易忽略的点：自定义Dataset的__getitem__方法要尽量轻量。我见过有人在__getitem__里做复杂的数据增强，结果num_workers开多了之后CPU成为瓶颈。正确的做法是把耗时的预处理放在__init__里或者离线做好，__getitem__只做必要的轻量操作。

6.2 学习率调度与优化器选择的实战经验

优化器选择上，Adam和SGD是两大主流。Adam收敛快、对学习率不敏感，适合快速实验；SGD泛化性能通常更好，但需要精细调参。我的习惯是：前期用Adam快速验证想法，确定模型结构没问题之后，再换SGD精调。

学习率调度方面，最常用的是StepLR和CosineAnnealingLR。StepLR每隔固定epoch降一次学习率，简单直接；CosineAnnealingLR按余弦曲线平滑下降，通常效果更好。还有一个OneCycleLR，先升后降，在不少任务上能加速收敛。

我踩过的一个坑是：用了学习率调度器但忘了调用scheduler.step()。结果学习率一直不变，训练后期loss震荡得厉害。后来养成了习惯，在每个epoch结束后打印当前学习率，确认调度器正常工作。

6.3 训练循环中的梯度裁剪与混合精度

梯度裁剪是防止梯度爆炸的常用手段，特别是RNN和Transformer这类模型。用法很简单：torch.nn.utils.clip_grad_norm_(model.parameters(), max_norm=1.0)。这个操作要在backward之后、optimizer.step()之前调用。

混合精度训练是另一个提速利器。PyTorch内置了torch.cuda.amp模块，用autocast上下文管理器和GradScaler就能实现。我实测过一个BERT微调任务，开启混合精度后训练速度提升了将近一倍，显存占用也降低了30%左右。需要注意的是，混合精度下loss scaling是必须的，否则小梯度会下溢为零。

还有一个训练技巧：梯度累积。当显存不够大、batch_size上不去的时候，可以用多个小batch累积梯度，等效于大batch训练。实现方式是在backward之前不清零梯度，累积若干步之后再统一step和清零。这在显存受限的场景下非常实用。

7. 踩坑实录：那些年我在PyTorch上栽过的跟头

7.1 显存溢出问题的完整排查链路

显存溢出（OOM）是PyTorch用户最常遇到的问题之一。我遇到OOM的时候，排查思路是这样的：第一步，用nvidia-smi看显存占用，确认是训练前就满了还是训练中逐渐涨满。第二步，如果是训练中涨满，检查是不是在循环里保存了张量导致计算图没释放。第三步，用torch.cuda.memory_summary()看详细的内存分配情况。

有一次我遇到一个诡异的情况：模型在第一个epoch正常，第二个epoch开始OOM。排查后发现是在验证阶段忘了加torch.no_grad()，导致验证集的前向传播也构建了计算图，显存一直累积。加上no_grad之后问题解决。这个教训让我养成了习惯：任何不需要梯度的前向传播，都加上no_grad。

还有一个隐蔽的OOM原因：在loss上做了in-place操作。比如有人写loss += aux_loss，如果loss本身需要梯度，这个原地操作会破坏计算图，导致PyTorch保留额外的中间变量。改成loss = loss + aux_loss就没问题了。

7.2 模型不收敛的常见原因与逐一排除

模型不收敛的原因很多，我一般按这个顺序排查：先看数据有没有问题（标签对不对、预处理有没有错），再看模型结构（维度对不对、激活函数合不合适），然后看超参数（学习率是不是太大或太小），最后看训练细节（梯度有没有正常回传、参数有没有更新）。

学习率过大是最常见的原因。表现是loss震荡剧烈或者直接变成nan。这时候把学习率降一个数量级试试，通常能解决。学习率过小则表现为loss下降极慢，训练半天没什么变化。我一般会用学习率扫描的方式，从1e-1到1e-5试几个值，找到下降最快的那个量级。

还有一个容易被忽略的原因：BatchNorm在小batch下表现不稳定。如果batch_size太小（比如小于8），BatchNorm的统计量估计不准，会导致训练不稳定。这时候可以换成GroupNorm或者LayerNorm，或者用SyncBatchNorm在多卡上同步统计量。

7.3 多卡训练中的同步问题与解决方案

多卡训练能加速，但也引入了新的问题。最常见的是BatchNorm的统计量不同步——每张卡各自计算自己的均值和方差，导致等效batch_size变小。解决方案是用SyncBatchNorm替换普通的BatchNorm，它会在所有卡之间同步统计量。

另一个问题是随机种子的同步。如果每张卡上的数据增强用了不同的随机种子，可能导致各卡看到的样本分布不一致。我一般会在训练开始前设置统一的随机种子，并且在DataLoader的worker_init_fn里也设置种子，确保可复现性。

还有一点：多卡训练时，保存模型要在主进程上做，否则每张卡都保存一遍，既浪费存储又可能冲突。用torch.distributed.barrier()同步各卡，然后只在rank 0上执行保存操作。加载模型的时候也要注意，用map_location参数指定设备，避免加载到错误的GPU上。

8. 性能调优：让训练速度再快一点

8.1 数据加载瓶颈的定位与优化

训练速度慢，很多时候瓶颈不在GPU而在数据加载。定位方法很简单：用torch.cuda.Event记录每个步骤的耗时，看数据加载时间和GPU计算时间的比例。如果数据加载占了大部分时间，那就是IO瓶颈。

优化数据加载的手段有几个：第一，把数据预处理成二进制格式（比如LMDB或者HDF5），比从磁盘读图片快很多。第二，用SSD而不是机械硬盘存数据。第三，增加num_workers，但要注意不要超过CPU核心数。第四，用prefetch_factor参数预取数据，让数据加载和GPU计算重叠。

我做过一个对比实验：同样的模型和数据，从JPEG图片直接读取训练，每个epoch要15分钟；转成LMDB之后，每个epoch只要8分钟。数据格式的优化带来的提升非常明显，而且是一次性投入长期受益。

8.2 模型推理加速的几种实用手段

推理阶段不需要反向传播，有很多加速手段可以用。最直接的是torch.no_grad()，前面已经提过。其次是模型量化，把FP32的权重转成INT8，推理速度能提升2-4倍，精度损失通常在1%以内。PyTorch提供了torch.quantization模块来做这件事。

另一个手段是TorchScript，把模型编译成中间表示，脱离Python解释器运行。TorchScript有两种模式：trace和script。trace适合没有控制流的模型，script适合有if/else的模型。编译后的模型可以用C++加载，部署到生产环境很方便。

还有ONNX导出，把PyTorch模型转成ONNX格式，然后用ONNX Runtime推理。ONNX Runtime对很多算子做了优化，在CPU上推理速度通常比原生PyTorch快。我一般会在模型定稿之后导出ONNX，用onnxruntime跑一遍benchmark，看看有没有明显的加速空间。

8.3 分布式训练的策略选择与配置要点

数据量特别大或者模型特别大的时候，单卡训练不现实，需要上分布式。PyTorch支持两种主要的分布式策略：DataParallel（DP）和DistributedDataParallel（DDP）。DP实现简单但效率低，因为有个主卡瓶颈；DDP效率高但配置稍复杂，需要用torch.distributed.launch或者torchrun启动。

我的建议是：能用DDP就用DDP，别用DP。DDP的加速比接近线性，8卡能跑到7倍多的速度；DP通常只能跑到3-4倍。DDP的配置也不复杂，主要是初始化进程组、用DistributedSampler切分数据、在模型外面包一层DDP。

还有一个细节：DDP模式下，每个epoch开始前要调用sampler.set_epoch(epoch)，否则每个epoch的数据切分方式都一样，影响训练效果。这个坑我踩过，当时发现每个epoch的loss曲线几乎一模一样，排查了好久才发现是忘了设置epoch。

9. 从实验到部署：PyTorch模型的落地路径

9.1 模型保存与加载的正确姿势

保存模型有两种方式：保存整个模型（torch.save(model, path)）和只保存参数（torch.save(model.state_dict(), path)）。我强烈推荐后者，因为只保存参数更灵活，加载的时候需要先实例化模型结构，然后load_state_dict。这样即使代码结构变了，只要参数名对得上就能加载。

加载的时候有个常见问题：在GPU上训练的模型，加载到CPU上会报错。解决方案是用map_location参数：torch.load(path, map_location='cpu')。反过来，CPU上训练的模型加载到GPU上，需要先load再.to(device)。

还有一个坑：多卡训练的模型保存时参数名会多一个module.前缀。如果直接用单卡加载会报key不匹配。解决方案是在保存的时候用model.module.state_dict()，或者在加载的时候去掉前缀。我一般会在保存前把模型包一层，统一处理这个问题。

9.2 模型导出与跨平台部署的注意事项

模型训练好之后，最终要部署到生产环境。部署方式取决于目标平台：如果是服务器端，可以用TorchServe或者自己写Flask/FastAPI接口；如果是移动端，可以用PyTorch Mobile；如果是浏览器，可以转成ONNX然后用ONNX.js。

导出ONNX的时候要注意算子兼容性。PyTorch的一些自定义算子可能没有对应的ONNX实现，导出会失败。解决方案是用ONNX支持的标准算子重写，或者注册自定义算子。另外，导出的时候要指定动态维度，否则输入尺寸固定，部署时不灵活。

我一般会在导出ONNX之后，用onnxruntime跑一遍验证，对比PyTorch和ONNX的输出差异。如果差异在1e-4以内，说明导出成功；如果差异很大，说明某个算子转换有问题，需要逐个排查。

9.3 版本升级带来的兼容性风险与应对

PyTorch版本更新很快，新版本可能引入不兼容的改动。我一般不会在生产环境追新，而是等新版本发布几个月、社区反馈稳定之后再升级。升级之前，先在测试环境跑一遍完整的训练和推理流程，确认没有报错。

常见的兼容性问题包括：API改名（比如torch.nn.functional里的一些函数）、默认行为变化（比如某些操作的默认参数变了）、废弃警告变成错误。应对方法是仔细阅读release notes，把废弃的API替换成新的写法。

还有一个经验：锁定依赖版本。在requirements.txt或者environment.yml里写死PyTorch和CUDA的版本号，避免因为自动升级导致环境不一致。团队协作的时候尤其重要，确保每个人跑出来的结果可复现。

10. 一些让我少走弯路的习惯

写了这么多，最后分享几个我在长期使用PyTorch过程中养成的习惯，都是实打实能省时间的。

第一个习惯：每个项目都写一个最小的可运行示例。不要一上来就写完整的训练脚本，先写一个几行代码的demo，确认环境没问题、数据能加载、模型能前向传播。这个demo跑通了，再往上加东西。这样出问题的时候，排查范围小，定位快。

第二个习惯：用TensorBoard或者WandB记录训练过程。loss曲线、学习率变化、梯度范数、权重分布，这些信息在排查问题时非常有用。我一般会在训练脚本里加几行代码记录这些指标，花不了多少时间，但省去了很多事后猜测。

第三个习惯：定期保存checkpoint。不要只保存最好的模型，每个epoch都存一份，万一训练崩了还能从最近的checkpoint恢复。checkpoint里除了模型参数，还要保存优化器状态、学习率调度器状态、当前epoch数，这样恢复的时候能完全接上。

第四个习惯：写单元测试。对自定义的层、损失函数、数据预处理逻辑，写几个简单的测试用例。PyTorch有torch.testing模块，用起来很方便。测试能帮你快速发现维度不匹配、数值不稳定之类的问题，比在训练中调试高效得多。

这些习惯看起来都是小事，但累积起来能显著提升开发效率。PyTorch本身已经足够灵活强大了，剩下的就是怎么把它用好、用顺。希望这些经验对你有帮助，少踩几个我踩过的坑。