Pipeline本身不防泄露，真正起作用的是cross_val_score或GridSearchCV在每折中独立调用pipe.fit()，确保StandardScaler等预处理器仅基于当前fold训练数据拟合，杜绝跨fold信息泄露。
因为Pipeline本身不防泄露，真正起作用的是它和cross_val_score或GridSearchCV配合时的调用方式——每折交叉验证都独立执行fit，预处理器只看到当前fold的训练数据。
仅使用 Python 将 Claw Code 虚拟化框架与 OpenClaw 集成，提供 184 种工具和 200 多条命令，用于安全分析和代码质量...
cross_val_score内部如何隔离每折的fit过程
当你写cross_val_score(pipe, X_train, y_train, cv=5)时，scikit-learn会在每个fold里：
• 从X_train和y_train中切出当前fold的训练子集（比如第1折取前80%）
• 对这个子集单独调用pipe.fit()，包括StandardScaler().fit()、SimpleImputer().fit()等全部步骤
• 这意味着scaler的均值、imputer的中位数，全基于该fold内那部分训练数据算出，绝不会沾上其他fold或测试集的统计量
• 错误做法是提前对整个X_train调用pipe.fit()，再传给cross_val_score——此时scaler已“记住”全部训练数据的均值，验证时transform实际用了未来信息
GridSearchCV为什么必须传未fit的pipeline
GridSearchCV的参数搜索过程本质也是多轮交叉验证，每组参数组合都要重跑完整CV流程：
• ✅ 正确：GridSearchCV(pipe, param_grid, cv=5) → 每次CV fold都新建pipeline并重新fit
• ❌ 错误：pipe.fit(X_train, y_train); GridSearchCV(pipe, ...) → 所有参数组合共享同一套预处理器参数，等于把验证折信息固化进模型
• 验证是否安全：检查cv_results_['param_scaler__with_mean']是否随参数变化而变化；若恒定，说明scaler没被重拟合，已污染
ColumnTransformer必须嵌在Pipeline顶层
当需要对数值列标准化、类别列one-hot时，ColumnTransformer常被误用为“预处理前置工具”：
• ❌ 危险：ct = ColumnTransformer(...); ct.fit(X_train) → 全局计算各列统计量，破坏fold隔离
• ✅ 安全：Pipeline([('preproc', ColumnTransformer(...)), ('clf', ...)])，再交给cross_val_score或GridSearchCV
• 关键点：任何预处理组件（包括ColumnTransformer）一旦脱离pipeline的fit生命周期，就失去fold级隔离能力
最容易被忽略的其实是时间维度——Pipeline能防统计泄露，但防不了时间错位。比如用全局日期分箱或未来滚动均值，哪怕放进Pipeline也照样泄露。防泄露不是套个类就完事，而是每一步操作都要问：这个值，在真实预测时能不能拿到？
