Featuretools需约束以防内存爆炸和特征冗余：设max_depth=1、限制agg_primitives、明确定义index/time_index；生成后须处理缺失值、标准化列名、删除方差为0列；复杂业务逻辑应手写特征。
Featuretools 能自动生成特征，但默认行为常导致内存爆炸或特征冗余——关键不在“能不能用”，而在“怎么约束它别失控”。
为什么 ft.dfs() 一跑就 OOM 或卡死
默认递归深度无限、实体间所有路径都尝试组合，尤其当时间变量缺失或关系未设主键时，会生成指数级特征（比如对每个用户生成 10⁴ 个统计量）。真实场景里，dfs 必须显式限制搜索空间。
-
max_depth=1：多数业务问题用 1 层聚合（如“用户最近 7 天订单数”）已够用；设为 2 就可能触发跨表嵌套计算，内存翻倍 -
agg_primitives=['count', 'mean']：禁用percentile、trend等高开销原语，它们需排序或拟合，单特征耗时是sum的 10 倍以上 - 确保每张表的
index和time_index明确指定，否则 Featuretools 会退化为笛卡尔积式扫描
如何让生成的特征真正可落地到模型训练
自动产出的特征名极长（如 PRODUCT.SUM(ORDER.LINE_ITEMS.PRICE)），且含大量缺失值——不能直接喂给 sklearn。必须做两件事：
- 用
feature_matrix.fillna(0)或fillna(method='ffill')处理缺失，避免后续fit()报ValueError: Input contains NaN - 用
feature_matrix.columns = [col.replace('.', '_').replace('(', '_').replace(')', '') for col in feature_matrix.columns]标准化列名，否则 XGBoost 会因列名含括号报错 - 删掉方差为 0 的列：
feature_matrix = feature_matrix.loc[:, feature_matrix.nunique() > 1]，避免 LightGBM 训练时警告 “feature name cannot contain special characters”
什么时候该放弃 Featuretools，改用手写特征
当业务逻辑强依赖顺序或状态机时，自动工具反而添乱。典型场景：
立即学习“Python免费学习笔记（深入）”；
- “用户第 3 次下单距注册天数”——需要按时间排序后取索引，
ft的nth原语不支持带条件的序位提取 - “最近一次订单是否含优惠券且支付成功”——涉及多字段联合判断，自动生成的布尔特征无法表达这种原子逻辑
- 实体关系是动态的（如“用户当前所属城市”随时间变化），而
EntitySet关系是静态定义的，无法建模时态归属
Featuretools 最有效的用法，是生成基础统计骨架（计数、均值、最值），再人工叠加 2–3 个关键业务规则特征——全自动不是目标，可控的半自动才是现实路径。
