Dropout层在eval()模式下未失效，根本原因是其training属性仍为True，常见于未纳入模型子树或forward中新建实例；设p=0比eval()更可靠地禁用Dropout。
Dropout 层在 eval() 模式下为什么没失效？
Dropout 层是否生效，不只看模型是否调用了 model.eval()，更关键的是它内部的 training 属性是否为 False。常见错误是：模型调用了 eval()，但某个子模块（比如单独定义的 nn.Dropout 实例）被绕过、未纳入模型结构，或在 forward 中被手动 new 出来——此时它完全不受 model.train()/model.eval() 控制。
- 检查 Dropout 实例是否属于模型的
nn.Module子树（即是否通过self.dropout = nn.Dropout(p)定义在__init__里） - 避免在
forward中写nn.Dropout(0.5)(x)—— 这会每次新建一个层，其training默认为True，且不随模型模式变化 - 可通过
print(model.dropout.training)直接验证该层当前状态
想彻底禁用 Dropout，设 p=0 和调用 eval() 哪个更可靠？
设 p=0 是硬性关闭，eval() 是条件关闭；两者逻辑不同，不能互相替代。设 p=0 后，无论 training=True 还是 False，输出都恒等于输入（因为丢弃概率为 0，且无缩放）；而 eval() 只影响 p > 0 时的行为——若 p=0，eval() 对它毫无意义。
-
nn.Dropout(0.0)在训练和推理中行为一致，完全透传，适合调试或临时关闭 -
nn.Dropout(0.5).eval()仅让该层跳过随机丢弃，但仍执行除以(1 - p)的缩放（PyTorch 实现中，eval()下仍保留 scale，但因无丢弃，scale 实际无效） - 生产环境建议优先用
p=0显式关闭，而非依赖模式切换——避免因忘记eval()或中间某层漏掉导致意外 dropout
torch.nn.Dropout 和 F.dropout 行为差异在哪？
torch.nn.Dropout 是模块类，状态绑定在实例上，响应 train()/eval()；F.dropout 是函数式接口，必须显式传入 training 参数，否则默认用 torch.is_grad_enabled() 判断——这容易引发隐蔽 bug，比如在 torch.no_grad() 下误触发 dropout 关闭，但实际你只想关梯度，不该动 dropout。
-
F.dropout(x, p=0.5)等价于F.dropout(x, p=0.5, training=torch.is_grad_enabled()) - 在
@torch.no_grad()装饰的函数里，F.dropout会自动变成 eval 模式，但如果你在训练中主动no_grad（如做 validation log），这就和预期不符 - 统一用
nn.Dropout+ 正确的model.train()/eval()更可控；仅当需要动态 p 或轻量级插入时才用F.dropout，且务必显式写training=model.training
验证 Dropout 是否真失效的最快方法
别只看 loss 或 acc 是否变化——那可能是其他因素干扰。最直接的方式是固定随机种子后，对比同一输入在 train/eval 模式下的输出张量值是否完全一致。
- 加
torch.manual_seed(42)和torch.backends.cudnn.deterministic = True - 构造一个简单输入
x = torch.ones(2, 10)，经过含nn.Dropout(0.5)的模型 - 分别运行
model.train(); y1 = model(x)和model.eval(); y2 = model(x)，用torch.allclose(y1, y2)检查 - 如果返回
False，说明仍有随机性——大概率是 Dropout 实例未被正确纳入模型，或用了F.dropout且training传错
Dropout 的“失效”不是开关式操作，而是由实例归属、p 值、调用方式、上下文训练状态四者共同决定；最容易被忽略的是：把 nn.Dropout 当工具函数用，而不是作为模型的一部分去管理。
