zero_grad()必须在loss.backward()之前且绝不能位于backward()和step()之间；否则step()将基于零梯度更新，导致参数不更新或更新错误。
zero_grad() 必须在 step() 之前，否则参数根本不会更新
因为 optimizer.step() 的行为是：读取当前所有参数的 .grad 值，按学习率缩放后，执行 param.data -= lr * param.grad。如果 zero_grad() 放在 step() 之后或中间，step() 就会基于一个已被清零（或部分清零）的 .grad 执行更新——结果就是「没更新」或「只更新了部分参数」。
常见错误写法：
loss.backward() optimizer.zero_grad() # ❌ 错！梯度刚算完就被清了 optimizer.step() # 此时 param.grad 是 0，等效于 w ← w - lr * 0
这种写法会导致模型完全不学习，loss 不降、accuracy 不变，但又不报错，极难排查。
为什么不能在 backward() 和 step() 之间调用 zero_grad()？
这是最隐蔽也最容易踩的坑。表面上看，backward() 已完成，梯度已存在；step() 还没执行，似乎“清一下也来得及”。但实际逻辑链是：backward() → 梯度写入 .grad → step() 读取并使用 → 更新完成。
-
zero_grad()清的是.grad张量的数值，不是“标记”或“锁” - 一旦清空，
step()就只能拿到全零梯度 - 即使你用
torch.no_grad()检查过参数变化，也会发现param.data完全没动
多优化器场景下更危险：比如 GAN 训练中 optimizer_g 和 optimizer_d 共享部分参数，若在某个 step() 前误调 zero_grad()，可能把另一个优化器刚算好的梯度也一并抹掉。
zero_grad() 放在循环开头 vs backward() 前瞬时，有区别吗？
从梯度计算正确性角度看，没区别——只要它发生在 loss.backward() 之前、且在 optimizer.step() 之前即可。但实操中推荐统一放在循环开头，原因很实际：
- 避免漏写：放在开头，每次迭代都强制重置，不容易被跳过
- 语义清晰：明确表示“本轮训练从干净梯度开始”
- 兼容梯度累积逻辑：如果后续要加
if step % accum_steps == 0:，开头调用 + 条件step()更易维护 - 防止意外前向传播干扰：比如你在
backward()前又跑了一次model(x)（调试时常见），开头清零能兜底
反例：有人把 zero_grad() 写在 loss.backward() 紧前，结果某次调试加了额外 forward，就导致梯度被意外累加。
不调用 zero_grad() 时，梯度到底怎么累加的？
PyTorch 的 backward() 默认行为是 acc_grad=True，即执行 param.grad.add_(computed_grad)。这意味着：
- 第一次
loss.backward()后：param.grad == g₁ - 第二次没清零就
loss.backward()：param.grad == g₁ + g₂ - 第三次：
param.grad == g₁ + g₂ + g₃
而 step() 永远只用当前 .grad 值更新一次。所以漏掉 zero_grad() 的后果不是“慢”，而是“方向错”：更新步长变成 η(g₁+g₂+…+gₙ)，等效于用超大 batch 训练但 loss 函数被悄悄替换了。实测中，3–5 轮后 loss 就可能爆炸到 inf 或 nan。
真正容易被忽略的点是：这个机制不是 bug，而是设计——它支撑着梯度累积（gradient accumulation）这种显存受限下的常用技巧。但默认训练流程里，你得自己负责关掉它，靠的就是那一行 optimizer.zero_grad()。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
