Optuna需手动定义试验闭环：目标函数内必须完成数据划分、交叉验证、指标计算及负号处理；参数采样需对数化（如lr、weight_decay）；Pruner需配合trial.report()和trial.should_prune()显式启用；所有trial须隔离、可复现。
Optuna 不是“设好参数就自动出最优解”的工具，它要求你亲手定义试验闭环——目标函数必须内部完成数据划分、交叉验证、指标计算和负号处理，否则跑 100 次 trial 可能还不如手动试一组。
目标函数必须自己做交叉验证，不能用全局 train/val 划分
常见错误是把 X_train、y_train 当作全局变量传进 objective，导致所有 trial 共享同一份训练集，验证结果严重过拟合。真正有效的做法是在每次 trial 内部重新划分或调用 cross_val_score。
- 用
StratifiedKFold手动做 5 折：确保每折的类别比例一致，尤其对小样本或不均衡数据 - 若用固定验证集，
StandardScaler.fit()必须只在当前 fold 的训练部分调用，不能在全量数据上 fit - 返回值必须是标量，且 Optuna 默认最小化——想最大化
accuracy就写return -score，或创建 study 时显式指定direction="maximize"
学习率、weight_decay 这类参数必须加 log=True
suggest_float('lr', 1e-5, 1e-2) 看似合理，但线性采样会让 90% 的 trial 落在 0.008–0.01 区间，根本覆盖不到 3e-4 这种关键值。对数采样才能在数量级间均匀试探。
- 适用
log=True的典型参数：lr、weight_decay、C（SVM）、reg_alpha（XGBoost） - 整数型同理：
suggest_int('max_depth', 3, 12, log=True)对树模型更有效；但n_estimators通常不用 log，因它与性能近似线性 - 类别型直接用
suggest_categorical('optimizer', ['adam', 'sgd', 'rmsprop'])，别用数字映射，否则日志难 debug
Pruner 不会自动生效，得靠 trial.report() 和 trial.should_prune()
默认的 MedianPruner 是哑巴——你不主动上报中间指标，它就永远不知道该砍哪条 trial。很多用户跑完发现 n_trials=50 实际只执行了 23 次，还以为是 bug，其实是 pruner 在起作用。
立即学习“Python免费学习笔记（深入）”；
- 必须在训练循环里每 epoch 调用
trial.report(val_loss, step=epoch)，step必须严格递增整数 - 紧接着判断：
if trial.should_prune(): raise optuna.TrialPruned() - 如果用
val_acc作为指标，记得direction="maximize"，否则 pruner 会把高 acc 当成“差表现”直接剪掉
复杂依赖关系要用嵌套 suggest_*，别让 Optuna 猜逻辑
比如选了 'SGD' 就不该再传 betas 给 torch.optim.Adam；又比如 n_layers=1 时 hidden_dim 设成 512 可能直接 OOM。Optuna 不会推理这种约束，必须显式编码。
- 用 if 分支控制：先
suggest_categorical('optimizer', ['adam', 'sgd'])，再根据值决定是否suggest_float('betas', ...) - 避免强耦合参数组合：
n_layers和hidden_dim一起搜容易梯度爆炸，建议固定一个或改用分段离散范围（如[64, 128, 256]） - 生产环境务必配
storage（如sqlite:///optuna.db），否则断电或中断后所有 trial 记录丢失
最容易被忽略的是：目标函数里的随机种子没重置，不同 trial 的数据 shuffle 结果不可复现；或者用了全局 model 实例，导致参数污染。每个 trial 都该是干净、隔离、可复现的一次完整训练生命周期。
