optuna需显式控制数据流与训练闭环，目标函数须封装完整训练-验证流程、内部划分数据、返回单一标量；超参如学习率需log=true采样；pruner需手动上报指标；生产环境必须配置storage实现持久化；每次trial须完全隔离。
目标函数必须封装完整训练-验证生命周期
常见错误是把 X_train、y_train 当作全局变量传入 objective，导致所有 trial 共享同一份划分，交叉验证失效，指标严重高估。
- 正确做法：在
objective内部完成数据划分，例如用StratifiedKFold或train_test_split（固定验证集时注意StandardScaler.fit()只能在每折训练子集上调用） - 若用
cross_val_score，确保传入的是原始数据，而非预处理后的全局特征矩阵 - 返回值必须是单一标量；要最大化
accuracy就写return -score，或创建 study 时指定direction="maximize" - 绝不能在外部调用
model.fit(X, y)——这等于把验证信息泄露进训练过程
学习率、正则项等数量级跨度大的参数必须加 log=True
suggest_float('lr', 1e-5, 1e-2) 默认线性采样，90% 的样本会挤在 0.008–0.01 区间，根本覆盖不到 1e-4 级别。这是多数人第一次跑不出好结果的核心原因。
- 正确写法：
trial.suggest_float('lr', 1e-5, 1e-2, log=True) - 同理：
trial.suggest_float('C', 1e-3, 1e3, log=True)（SVM / LogisticRegression） -
trial.suggest_int('max_depth', 3, 12, log=True)（小范围树深度适用） - 但
n_estimators通常不用log=True，因它与性能近似线性关系
Pruner 不会自动生效，必须手动上报中间指标
即使配置了 MedianPruner 或 SuccessiveHalvingPruner，若没在训练循环中调用 trial.report() 和 trial.should_prune()，剪枝就永远不会触发。
- 每 epoch 或每 N 步验证后，执行
trial.report(val_loss, step=epoch) - 紧接着判断
if trial.should_prune(): raise optuna.TrialPruned() - 漏掉任一环节，pruner 就是摆设；报错的指标（如误报
train_loss）会让剪枝逻辑完全错位
生产环境必须配 storage，否则断点续跑失败
默认 in-memory 模式只保存在当前 Python 进程里。一旦中断或重启，全部 trial 记录丢失——跑 100 次 trial 中断在第 87 次？没 storage 就得重来。
- 最简持久化：
study = optuna.create_study(storage="sqlite:///study.db") - 多进程/分布式场景必须用 RDBMS（如 PostgreSQL），SQLite 不支持并发写入
- 注意路径权限：确保进程对
study.db所在目录有读写权，否则静默失败
suggest_*，而是每次 trial 是否真的彼此隔离：模型实例、dataloader、随机种子、device 分配、预处理拟合范围——这些不重置，所有 trial 的评估结果就不可比。Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
