optuna不是黑盒工具，需显式定义试验闭环、隔离数据流、管理评估节奏：目标函数内须完成独立数据划分与验证，数量级跨度大的参数需设log=true，pruner需手动上报指标并触发剪枝，生产环境必须配置storage以支持断点续跑。
Optuna 不是“扔进去自动出最优解”的黑盒。它要求你显式定义试验闭环、控制数据流边界、并主动管理评估节奏——否则跑完 100 次 trial，结果可能还不如手动试两组。
目标函数必须封装完整训练-验证生命周期
常见错误是把 X_train、y_train 当作全局变量传入 objective，导致所有 trial 共享同一份划分，交叉验证失效。正确做法是在函数内部完成划分与验证逻辑：
- 用
train_test_split或StratifiedKFold划分，确保每次trial独立采样 - 若用固定验证集，
StandardScaler.fit()只能在训练折上调用，不能在全量数据上拟合 - 返回值必须是标量，且默认按最小化处理：要最大化
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 级别。这类参数必须加 log=True：
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 或每 step 后调用
trial.report(val_loss, step=epoch) - 紧接着判断
if trial.should_prune(): raise optuna.TrialPruned() - 没做这两步，
pruner就只是个摆设；很多用户跑完发现所有trial都跑满 epoch，就是漏了这个
生产环境必须配 storage，否则断点续跑失败
默认 in-memory 模式只保存在当前 Python 进程里。一旦中断或重启，全部 trial 记录丢失：
- 用 SQLite：
storage="sqlite:///study.db" - 用 RDBMS（如 PostgreSQL）支持多进程并发写入
-
study.optimize(..., n_trials=100)中断后，下次只需再跑n_trials=100，Optuna 自动跳过已存在的trial - 不设
storage，就等于每次从头开始，历史信息完全不可复用
scaler.fit(X) 写在 objective 外部，整个搜索过程的泛化性就崩了。Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
