根本原因是训练与转换时输入列数不一致；应统一用DataFrame输入、避免混用Series，显式检查shape和type，推荐使用ColumnTransformer对齐列名与顺序。
用 OneHotEncoder 处理类别特征时，为什么 fit 后 transform 报错 ValueError: X has 1 features, but OneHotEncoder is expecting 2 features？
根本原因是训练时传入的 X 和预测/转换时传入的 X 列数不一致——常见于手动切片、丢列、或 pandas DataFrame 转 numpy 后索引错位。例如用 df[['col_a']] 训练，却用 df['col_a'].values.reshape(-1, 1) 去 transform，后者是二维但 shape 可能被误判。
实操建议：
- 统一用
pd.DataFrame输入，避免混用Series和DataFrame；OneHotEncoder对Series的处理行为不稳定 - 训练前显式检查：
print(X_train.shape)和print(type(X_train))，确保是二维结构 - 用
ColumnTransformer替代手写列选择，自动对齐列名和顺序，避免人为漏列 - 若必须手动选列，用
df.loc[:, ['col_a', 'col_b']]而非df[['col_a', 'col_b']]（虽等价，但更显式）
高维稀疏矩阵下 fit_transform 内存爆掉，该用 fit+transform 分开还是换算法？
分开调用不能缓解内存压力——fit_transform 的峰值内存主要来自编码后稠密中间态（尤其类别数多+样本多），不是函数调用方式的问题。
真正有效的做法：
立即学习“Python免费学习笔记（深入）”；
Secure Python Code Sandbox
下载
安全 Python 代码沙箱：在隔离的沙箱中执行任意 Python 代码，预装 requests、NumPy、pandas 库。返回 stdout、stderr。
- 启用
sparse_threshold=0.0（默认是 0.3）强制返回scipy.sparse矩阵，避免隐式转稠密；注意：后续模型需支持稀疏输入（如LogisticRegression、RandomForestClassifier默认支持，SVM不支持） - 对高频类别做
handle_unknown='ignore'+ 预先合并低频类别（如出现频次 'other'），直接减少列数 - 改用
TargetEncoder或LeaveOneOutEncoder（来自category_encoders），它们输出稠密低维向量，适合后续全连接网络或树模型 - 不用
pd.get_dummies，它默认返回稠密pd.DataFrame，且不保存编码映射，无法复用于新数据
类别列含 NaN，OneHotEncoder 报 TypeError: Encoders require their input to be uniformly strings or numbers 怎么办？
这是 OneHotEncoder 在 scikit-learn np.nan 当作 object 类型，而列中同时有 string 和 nan 就被判为“类型不统一”。1.0+ 版本已支持 encode='ignore' 参数，但默认仍失败。
稳妥解法：
- 训练前统一填充：
df[col] = df[col].fillna('MISSING')（字符串列）或df[col] = df[col].fillna(-1)（数值型编码列），再进 encoder - 用
sklearn.impute.SimpleImputer(strategy='constant', fill_value='MISSING')配合ColumnTransformer，保证训练/预测流程一致 - 避免用
dropna=True删除含 nan 行——线上 inference 时 nan 必然存在，训练和部署逻辑必须一致 - 确认 pandas 版本 ≥ 1.3，scikit-learn ≥ 1.0，并显式设置
OneHotEncoder(handle_unknown='ignore', sparse_output=True)
稀疏矩阵传给 RandomForestClassifier 训练慢，甚至卡死，是不是该转成稠密？
不该转。转稠密（.toarray()）大概率直接 OOM；而“慢”往往是因为没关掉稀疏检查或用了不兼容的预处理步骤。
关键排查点：
- 确认是否在 pipeline 中混用了
StandardScaler——它不支持稀疏矩阵，会触发隐式 densify，必须换成StandardScaler(with_mean=False)（因为稀疏矩阵均值为 0 才可跳过中心化） - 检查是否用了
PCA或TruncatedSVD：前者不支持稀疏，后者支持，但需设n_iter='auto'加速 SVD 分解 - 随机森林本身对稀疏输入无性能惩罚，但如果上游用了
CountVectorizer或TfidfVectorizer生成极高维稀疏矩阵（如 >100 万列），建议先用HashingVectorizer降维 - 用
joblib.dump保存稀疏矩阵时加compress=3，避免 pickle 后体积暴增
高维稀疏处理最易被忽略的点：不是编码方法本身，而是整个 pipeline 中任意一个组件悄悄把稀疏转稠密——这种转换往往静默发生，只在大流量 infer 时暴露。
