LabelEncoder仅适用于目标变量y或明确有序的单列特征，误用于无序特征会引入虚假序关系；OneHotEncoder需预先处理NaN并用ColumnTransformer分列编码，pd.get_dummies适合探索而OneHotEncoder保障生产一致性。
LabelEncoder 什么时候会悄悄搞坏你的模型
它只适合目标变量（y），千万别拿它去编码特征列（X）——尤其当特征本身有顺序含义时，比如“低/中/高”，LabelEncoder 会强行变成 0/1/2，模型就误以为“高”是“低”的两倍大。
- 常见错误现象：
ValueError: X has 3 features, but LabelEncoder was fitted on 1，其实是调用顺序错了，但更危险的是没报错却训出了假相关 - 使用场景：仅限
y（分类标签）；或极少数明确有序的单列特征（如评级），且你确定模型能正确解读整数序关系 - 参数差异：
LabelEncoder没有handle_unknown或sparse参数，遇到训练时没见过的新类别直接崩 - 性能影响：快，内存省，但破坏特征原始语义，树模型可能扛得住，线性模型和神经网络基本会偏移
OneHotEncoder 处理字符串特征必须先填空
只要列里有 NaN，OneHotEncoder 默认直接报错：TypeError: Encoders require their input to be uniformly strings or numbers。它不猜、不跳、不默认填充——得你先动手。
- 常见错误现象：明明数据看着都“是字符串”，但一 fit 就崩，大概率是混了
NaN或None - 实操建议：
df[col] = df[col].fillna("MISSING")，别用空字符串，避免和真实空值混淆；如果列本就是数值型但要当类别用，先df[col] = df[col].astype(str) - 兼容性注意：sklearn 1.0+ 的
OneHotEncoder默认drop=None，容易引发共线性；建模前建议设drop="first"或配合LinearRegression(fit_intercept=False) - 稀疏输出：默认返回稀疏矩阵，转
.toarray()会吃光内存；保留稀疏格式，大多数 sklearn 模型原生支持
pd.get_dummies 和 OneHotEncoder 到底选谁
简单探索或快速 baseline 用 pd.get_dummies 更顺手；但进生产 pipeline、要部署、或训练/预测数据分布不一致时，必须用 OneHotEncoder。
- 关键区别：
pd.get_dummies是函数式、无状态的，每次调用都重算；OneHotEncoder是类实例，fit 后能用同一个对象 transform 新数据，保证列对齐 - 新类别处理：
pd.get_dummies遇到未见过的值就忽略；OneHotEncoder在handle_unknown="ignore"下可安全跳过，设为"error"（默认）则报错，可控性强 - 路径依赖：
pd.get_dummies生成的列名带原始列名前缀，但不会记录哪些值被编码了；OneHotEncoder的categories_属性明明白白记着每个特征的所有取值顺序，debug 和复现都靠它
混合类型 DataFrame 编码不能只靠一个 fit
想对部分列用 OneHotEncoder、部分列用 StandardScaler、再丢几列进去？别直接往整个 df 上硬套——OneHotEncoder 会把数值列也当类别轰成一堆 0/1，StandardScaler 会对字符串列报错。
立即学习“Python免费学习笔记（深入）”；
- 必须分列处理：用
ColumnTransformer显式指定每组列的处理器，例如transformers=[("cat", OneHotEncoder(), ["city", "grade"]), ("num", StandardScaler(), ["age", "income"])] - 容易踩的坑：传给
ColumnTransformer的列名必须和 DataFrame 实际列名完全一致（包括空格、大小写），否则静默跳过，结果维度对不上 - 性能提示：
ColumnTransformer默认并行（n_jobs=1），但若各步骤耗时差异大，设n_jobs=None反而更稳；调试阶段先关掉并行，错误堆栈更清晰
最常被忽略的一点：OneHotEncoder 的 categories_ 在 fit 后才存在，但很多人在没 fit 前就试图访问它——结果 AttributeError。不是文档没写清楚，是忘了 encoder 本质是“学出来的映射”，不是配置文件。
