PyTorch eval()时BN层使用被小batch污染的running_mean/var导致异常，并非BN损坏；应调低momentum、设track_running_stats=False或递归调用eval()确保全模块生效。
PyTorch eval() 时 BN 层用的是“假统计量”
不是 BN 层坏了，而是它在 model.eval() 下被迫使用训练中累积的 running_mean 和 running_var —— 这些值本该靠大 batch 稳定更新，但实际训练时 batch size 很小（比如 1~4），导致每个 batch 的均值/方差剧烈抖动，滑动平均被严重污染。测试时一用这些“有毒”的统计量归一化，特征就全乱了。
常见现象包括：
- 验证 loss 突然飙升（比如从 8 跳到 35+）
- 同一张图多次推理结果不一致（即使加了
torch.no_grad()） - 切换回
model.train()后 loss 立刻恢复正常
momentum=0.1 实际是“慢更新”，不是“快遗忘”
PyTorch 的 momentum 参数和常规优化器相反：running_mean_new = (1 - momentum) * running_mean_old + momentum * batch_mean。默认 momentum=0.1 意味着新 batch 统计量只占 10%，旧值占 90% —— 更新极慢。小 batch 下，这种保守策略反而让坏统计更难被覆盖。
可尝试的调整方式：
立即学习“Python免费学习笔记（深入）”；
- 训练时显式设
momentum=0.01或更低，让running_mean/var更快响应真实分布 - 或直接设
momentum=0（等价于取所有 batch 的算术平均），但需确保训练足够长 - 注意：改
momentum必须在模型初始化时设定，训练中途修改无效
track_running_stats=False 是最干净的绕过方案
如果任务场景允许（如检测/分割中 backbone 常被微调且 batch 极小），直接禁用 BN 的全局统计机制，让它在 train/eval 模式下都用当前 batch 的统计量 —— 虽然 eval 时 batch=1 会退化为减均值除标准差，但至少不会用错历史值。
操作方式（对所有 BN 层生效）：
def disable_bn_running_stats(model):
for m in model.modules():
if isinstance(m, (torch.nn.BatchNorm2d, torch.nn.BatchNorm1d)):
m.track_running_stats = False
调用时机：模型加载权重后、训练前执行一次即可。注意这会改变 BN 行为本质，需同步评估对收敛性和最终精度的影响。
eval() 不等于“全模型进入 eval 状态”
仅调用 model.eval() 并不能保证嵌套子模块（如自定义 Stack、Block 或第三方库组件）也同步切换。某些结构里 Dropout 或 BN 可能藏在未被 model.children() 直接遍历到的深层 submodule 中。
安全做法是递归应用：
model.eval()
for module in model.modules():
if hasattr(module, 'eval'):
module.eval()
更稳妥的写法是用 apply()：
model.apply(lambda m: m.eval() if hasattr(m, 'eval') else None)
复杂模型部署前，务必用 print(list(model.modules())) 手动确认关键 BN/Dropout 层是否真处于 training=False 状态。
BN 层在 eval 模式下的异常，本质是训练统计与推理假设之间的错配。问题不在代码写错，而在小 batch 场景下默认参数不再适用 —— 需要主动干预统计更新逻辑，而不是被动等待“自动收敛”。
