cross_val_score本身不污染测试集，污染源于代码错误；正确做法是将standardscaler等预处理器与模型封装进pipeline，确保每折独立拟合和变换，且全程使用原始数据配合timeseriessplit等专用cv对象。
cross_val_score 本身不会污染测试集——污染永远来自你写的代码，而不是函数名。
StandardScaler 在 cross_val_score 外部调用是典型污染源
很多人写成这样：
X_scaled = StandardScaler().fit(X).transform(X)
scores = cross_val_score(RandomForestClassifier(), X_scaled, y, cv=5)
这等于把整个 X 的均值和方差“泄露”给了每折的训练过程。测试折里的样本在标准化时用了自己未来才该知道的全局统计量，模型实际看到的是“作弊后的数据”。
正确做法只有一条：预处理器必须和模型一起放进 Pipeline，让 fit 和 transform 都限制在当前训练折内。
-
StandardScaler每折只用该折的训练子集计算均值/方差 -
SimpleImputer每折只用该折训练子集的中位数填充 -
SelectKBest每折只基于该折训练子集筛选特征
不封装进 Pipeline，就等于没做交叉验证。
train_test_split + cross_val_score 组合会悄悄破坏结构约束
常见错误流程：
X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.2)
scores = cross_val_score(model, X_train, y_train, cv=5)
表面看没问题，但问题出在：
- 如果原始数据有时间顺序，
train_test_split默认随机打乱，把“未来”样本混进了X_train； - 如果数据带分组（如用户ID、医院编号），
train_test_split可能把同一组样本拆到训练折和测试折里； - 这时再对
X_train做cross_val_score，各折之间已失去隔离性，评估结果虚高。
真正安全的做法是：
- 全程只用一个
cv对象生成所有划分，比如TimeSeriesSplit或GroupKFold(groups=groups)； -
cross_val_score的X和y必须是原始未切分的全量数据； - 测试集信息从不参与任何拟合步骤，包括预处理、特征选择、超参搜索。
GridSearchCV 嵌套在 cross_val_score 里等于双重污染
错误写法：
grid = GridSearchCV(RandomForestClassifier(), param_grid, cv=3)
scores = cross_val_score(grid, X, y, cv=5)
这会导致外层 5 折每折都跑一次内层 3 折网格搜索——不仅慢，更严重的是：
- 内层 CV 已经在用部分“测试折”调参，外层又把它当验证折用；
- 参数选择过程看到了多轮验证集，等价于用验证集信息反复优化，最终评估不再反映泛化能力。
需要调参时，应直接用 GridSearchCV 本身做完整评估，或升级为嵌套交叉验证（cross_val_score 套 GridSearchCV 是反模式）。
Pipeline 不是锦上添花的写法，而是防止污染的最低门槛。哪怕只是加一行 from sklearn.pipeline import Pipeline，也比裸跑 cross_val_score 安全得多。最容易被忽略的点是：所有 fit 调用都必须发生在单折训练子集上，且不能跨折共享任何中间结果。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
