featureengine 需显式声明每步变换以确保可复现与防泄漏：meanencoder 与 ordinalencoder 不可混用同一列，categoricalimputer 必须在 train-test 分离后仅对训练集拟合，datetimefeatures 需手动指定 variables 和 output_variables 避免列名冲突。
FeatureEngine 不是“开箱即用”的全自动流水线，它提供的是可组合、可复用、可解释的特征变换模块；直接套用默认参数往往导致数据泄漏或无效特征。
为什么 MeanEncoder 和 OrdinalEncoder 不能混着用在同一个分类变量上
两者目标不同：前者用目标均值编码（需目标变量参与），后者仅做标签映射（无监督）。若先用 MeanEncoder 再用 OrdinalEncoder，会破坏均值编码的统计一致性；更严重的是，MeanEncoder 默认执行组内均值计算时若未设置 cv=3 或 smoothing，在小样本类别上极易过拟合。
实操建议：
- 对高基数分类变量（如用户ID），优先用
MeanEncoder+smoothing=10防噪 - 对低基数且与目标强相关变量（如“是否VIP”），用
OrdinalEncoder更稳定 - 绝不在同一列上串联多个编码器——FeatureEngine 的设计哲学是“一列一变换”，不是“一列多步骤”
用 CategoricalImputer 填充缺失值前必须确认训练集/测试集分离已完成
CategoricalImputer 默认用训练集众数填充，但如果你在 train-test 划分前就调用它，填充依据会混入测试样本分布，造成数据泄漏。错误现象常表现为 CV 得分远高于线上效果。
实操建议：
- 所有 imputer 必须在
train_test_split之后、仅对X_train调用fit()，再对X_train和X_test分别调用transform() - 避免使用
fit_transform(X_train)后直接transform(X_test)——看似合理，但某些 imputer（如DropMissingData）不支持transform()，必须显式区分阶段 - 用
pipeline封装时，确保 imputer 在 pipeline 中处于最前端，且 pipeline 仅对X_train调用fit()
DateTimeFeatures 提取的列名默认不带原始字段前缀，容易引发列名冲突
比如你有两个时间列 order_time 和 ship_time，都启用 features_to_extract=["month", "day_of_week"]，结果会生成两组同名列：month、day_of_week，后续无法区分来源。
实操建议：
- 始终手动传入
drop_original=False并配合variables显式指定单个时间列，例如：DateTimeFeatures(variables=["order_time"], features_to_extract=["month"]) - 需要批量处理时，用循环构造多个独立 transformer，每个指定不同
variables和自定义output_variables（该参数需 FeatureEngine ≥ 1.7.0） - 提取后立刻检查
transformer.get_feature_names_out()，确认列名唯一且可追溯
FeatureEngine 的真正价值不在省代码，而在强制你把每一步变换显式声明、可复现、可审计。最容易被忽略的是：所有 transformer 的 fit() 都依赖训练集统计量，一旦你用 pandas.DataFrame.fillna() 预处理过数据，再喂给 FeatureEngine，就可能让它的内部统计失效——所以预处理和 FeatureEngine 变换之间，不能有隐式的数据改动。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
