是，目标函数必须在每次trial中独立完成数据划分、训练、验证并返回单一标量；否则结果不可复现甚至劣于随机调参，因共享训练集导致交叉验证失效，且预处理须严格限制在每折训练子集上。
直接上手 Optuna 前，必须确认：目标函数是否在每次 trial 中独立完成数据划分、训练、验证并返回单一标量？如果不是，结果大概率不可复现，甚至比随机选参数还差。
objective 函数必须自己做 K 折验证，不能用全局 train/val 划分
常见错误是把 X_train、y_train 作为外部变量传进 objective，导致所有 trial 共享同一份训练集——交叉验证失效，评估严重高估。
- 正确做法：在
objective内部调用cross_val_score，或手动实现 K 折（如用StratifiedKFold） - 若坚持用固定验证集，确保预处理（如
StandardScaler.fit()）只在每折的训练子集上调用，绝不能在全量X_train上 fit - 返回值必须加负号（如
return -score），除非显式指定direction="maximize"
学习率、weight_decay 等数量级跨度大的参数必须用 log=True
线性采样（如 suggest_float('lr', 1e-5, 1e-2)）90% 的样本会挤在 0.009–0.01 区间，根本试不到 1e-4 级别。这是多数人第一次跑不出好结果的核心原因。
- 正确写法：
trial.suggest_float('lr', 1e-5, 1e-2, log=True) - 整数型同理：
trial.suggest_int('max_depth', 3, 12, log=True)（适用于树模型深度） -
n_estimators通常不用log=True，因它和性能近似线性关系 - 类别型必须用
suggest_categorical('optimizer', ['adam', 'sgd'])，别映射数字再查表
pruner 不会自动生效，必须手动上报中间指标
设了 MedianPruner 却没看到任何 trial 被提前终止？因为你没在训练循环里调用 trial.report() 和 trial.should_prune()。
- 每 epoch 或每 N 步验证后，必须执行
trial.report(val_loss, step=epoch) - 紧接着判断
if trial.should_prune(): raise optuna.TrialPruned() - 不这么做，pruner 就是摆设；而乱报指标（比如报 train_loss）会导致剪枝逻辑完全错位
生产环境必须配 storage，否则断点续跑会丢历史
本地 SQLite 默认路径是内存或临时文件，重启 Python 进程后所有 trial 记录消失。跑 100 次 trial 中断在第 87 次？没 storage 就得重来。
- 最简持久化：
study = optuna.create_study(storage="sqlite:///db.sqlite3", ...) - 多进程/分布式场景必须用 RDBMS（如 PostgreSQL），SQLite 不支持并发写入
- 注意路径权限：确保进程对
db.sqlite3所在目录有读写权，否则静默失败
最容易被忽略的点是：Optuna 不保证“跑完 n_trials 就一定收敛”，它只保证每次 trial 都比上次更聪明地采样。如果你的 objective 返回值波动极大（比如 DRL 的 reward、小样本任务的 CV score），就得配合更保守的 pruner 和更高的 n_startup_trials，否则前 20 次 trial 就可能误杀潜力组合。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
