仅设 requires_grad=False 不足，须确保优化器仅接收可训参数，否则冻结无效；需在构造优化器前筛选参数或重建优化器，并保持 model.train() 以更新 BN 统计量。
只设 requires_grad = False 不够，必须同步确保优化器不接收这些参数，否则冻结无效。
为什么 requires_grad = False 后模型还在更新？
常见现象：训练中打印 model.layer1[0].conv1.weight.grad 是 None，但权重值却在变；或者 loss 下降但验证集 acc 卡住不动。
根本原因不是梯度没算——而是优化器仍持有该参数引用，并用零梯度或旧梯度覆盖它。PyTorch 的 torch.optim.Adam 或 SGD 会无条件更新所有传入的参数，不管 requires_grad 是真是假。
- 必须在构造优化器前，用
filter(lambda p: p.requires_grad, model.parameters())筛出可训参数传入 - 如果优化器已创建，改完
requires_grad后不能“热更新”，得重建优化器（手动清空param_groups风险高，不推荐） - 验证是否生效：训练中检查
sum(p.grad is not None for p in model.parameters() if p.requires_grad)应 > 0；冻结层的p.grad必须始终为None
按层名匹配冻结比按索引更稳
用 list(model.children())[-2:] 解冻最后两层，在 nn.Sequential 或 ViT 这类嵌套结构里极易失效——因为子模块可能不是直接可索引的 nn.Module，或者内部还有 nn.Sequential 包裹。
立即学习“Python免费学习笔记（深入）”；
更可靠的方式是遍历 named_parameters()，按字符串匹配层名：
- ResNet 类模型常用：
"layer4"、"fc"、"classifier" - ViT 常用：
"encoder.layer.10"、"head"、"norm" - 避免写死
"conv1"这类泛化名，容易误伤 backbone 中多个同名卷积 - 冻结后立刻打印
sum(p.numel() for p in model.parameters() if p.requires_grad)，确认非零且数量合理（比如 ResNet18 微调fc层应剩约 1000 × 512 + 1000 ≈ 513k 参数）
model.train() 和冻结完全无关，但必须开着
很多人冻结后顺手加了 model.eval()，结果 BN 层卡在运行统计量上，小 batch 下特征分布剧烈偏移，loss 初期猛跌后卡死。
-
model.eval()只影响Dropout、BatchNorm等层的行为，不改变requires_grad - 微调阶段必须保持
model.train()，否则BatchNorm不更新 running stats，等效于“冻结了归一化能力” - 若数据极少、BN 统计不稳定，可临时关掉 track：
model.apply(lambda m: setattr(m, 'track_running_stats', False) if isinstance(m, torch.nn.BatchNorm2d) else None)，但这是调试手段，不是常规操作
requires_grad_() 和 requires_grad = False 没本质区别
两者效果一致，requires_grad_() 是就地修改的函数式写法，更常用于链式调用；但注意它不递归作用于子模块。
-
model.fc.requires_grad_(True)只开fc模块自身参数，如果fc是nn.Sequential，里面每层还得单独设 - 真正要递归开关，得写循环：
for param in model.fc.parameters(): param.requires_grad = True - 别混用：不要先
model.fc.weight.requires_grad = False，再model.fc.requires_grad_(True)——后者不会恢复子参数状态
最易被忽略的点：冻结逻辑写在模型定义之后、优化器创建之前，且必须和 model.train() 配合使用；任何一步顺序错位，都会让“冻结”变成幻觉。
