标签泄露本质是训练数据混入测试标签，主因是预处理挪到cross_val_score外部；Pipeline不自动防泄露，安全依赖cross_val_score或GridSearchCV内部每折独立fit。
标签泄露（Label Leakage）在交叉验证中本质是训练数据里混入了测试样本的标签信息，最常见诱因是把预处理步骤挪到 cross_val_score 外部执行——Pipeline 本身不自动防泄露，关键在于**谁调用 fit、在哪儿调用**。
cross_val_score(pipe, X, y, cv=5) 是安全的，但 pipe.fit(X, y) 后再传进去就危险
很多人误以为只要用了 Pipeline 就万事大吉，其实真正起作用的是 cross_val_score 的内部机制：它会在每个 fold 内部对当前训练子集单独调用 pipe.fit()，包括 StandardScaler 或 SimpleImputer 的 fit 都只看到该 fold 的训练数据。
- ✅ 安全写法：
cross_val_score(pipe, X_train, y_train, cv=5)—— 每折独立拟合全部 pipeline 步骤 - ❌ 危险写法：
pipe.fit(X_train, y_train); cross_val_score(pipe, X_train, y_train, cv=5)—— scaler 已用全部训练数据拟合，验证折的 transform 实际用了“未来信息” - ⚠️ 注意：
X_train和y_train必须是划分好的、未被全局预处理过的原始数据
GridSearchCV 调参时，pipeline 必须作为 estimator 传入，不能先 fit
GridSearchCV 内部也依赖交叉验证逻辑，如果提前对整个 X_train 调用 pipe.fit()，那所有参数组合都会共享同一套 scaler 参数，等于把验证折的信息“固化”进了预处理器。
- ✅ 正确：
GridSearchCV(pipe, param_grid, cv=5)—— 每次 CV fold 都重建 pipeline 并重新fit - ❌ 错误：
pipe.fit(X_train, y_train); GridSearchCV(pipe, ...)—— 预处理器已污染，搜索结果不可信 - ? 验证是否安全：检查
GridSearchCV输出的cv_results_['param_scaler__with_mean']是否随参数变化而变化；若恒定，说明 scaler 没被重拟合
ColumnTransformer 必须嵌套在 Pipeline 顶层，不能单独 fit
当需要对不同列做不同变换（如数值列标准化、类别列 one-hot），ColumnTransformer 常被误当作“预处理前置工具”。但它一旦单独 fit，就会用全部 X_train 计算统计量，破坏 fold 隔离。
立即学习“Python免费学习笔记（深入）”；
- ✅ 安全结构：
Pipeline([('preproc', ColumnTransformer(...)), ('clf', LogisticRegression())]) - ❌ 危险结构：
ct = ColumnTransformer(...); ct.fit(X_train); X_train_ct = ct.transform(X_train)—— 此时X_train_ct已含泄露 - ? 提示：
ColumnTransformer的remainder='passthrough'或'drop'行为，在 pipeline 中仍受 fold 约束，无需额外处理
时间序列或分组数据必须禁用 shuffle，否则 label 泄露更隐蔽
标准 cross_val_score 默认 shuffle=True，这对普通数据没问题，但对时间序列或按用户/设备分组的数据，shuffle 会打乱时序或混入同组其他样本的标签信息，造成隐性泄露。
- ✅ 时间序列：用
TimeSeriesSplit，且确保shuffle=False - ✅ 分组数据：用
GroupKFold，传入groups参数，并显式设shuffle=False - ⚠️ 关键点：即使 pipeline 写得再规范，若 CV 策略本身违反数据结构约束，泄露仍会发生
最容易被忽略的是：Pipeline 只封装流程，不自动绑定数据生命周期。真正的防线在调用方式——所有 fit 动作必须发生在交叉验证框架内部，而不是你手动触发。一旦你写了 pipe.fit(...)，就等于交出了控制权。
