OneHotEncoder 默认会崩，因 sparse_threshold=0.3 可能触发稠密降级；OrdinalEncoder 乱用于线性模型会引入错误数值关系；可靠组合是 OneHotEncoder(sparse_threshold=0.0) + ColumnTransformer + 稀疏感知模型。
直接上结论：对大规模类别特征，OneHotEncoder 默认会爆内存，OrdinalEncoder 不能直接用于树模型外的线性模型，真正靠谱的组合是 OneHotEncoder(sparse_threshold=0.0) 配合 ColumnTransformer + 稀疏矩阵下游处理。
为什么 OneHotEncoder 默认会崩？
Scikit-learn 1.0+ 版本中，OneHotEncoder 默认启用稀疏输出（sparse=True 已弃用），但关键在 sparse_threshold 参数：它控制“当独热后稀疏度低于该阈值时，强制转为稠密数组”。默认值是 0.3，意味着只要超过 30% 的位置是非零，就放弃稀疏格式——而类别数一多（比如 1000 个唯一值），哪怕每个样本只激活 1 列，整体稀疏度仍是 99.9%，本该保持稀疏；但若某列高频（如 “unknown” 占 40%），就可能触发稠密降级，瞬间吃光内存。
- 实操建议：显式设
sparse_threshold=0.0，强制全程稀疏 - 验证是否生效：编码后检查
.format属性，应为'csr'或'csc' - 注意：
LinearRegression、Ridge等支持稀疏输入，但StandardScaler不支持——别把它接在OneHotEncoder后面
类别数超万时，OrdinalEncoder 为什么不能乱用？
OrdinalEncoder 只是把字符串映射成整数，不带语义。问题在于：它生成的序数会被下游模型当作“有序连续量”处理。树模型（RandomForestClassifier）对此不敏感；但线性模型、SVM、神经网络会错误地认为 “category_A=1” 和 “category_B=10000” 之间有 9999 倍的数值关系。
- 仅在明确知道类别天然有序（如 “low/medium/high”）且模型是树系时可用
- 若强行用于
LogisticRegression，必须配合OneHotEncoder或目标编码（target encoding） - 替代方案：
TargetEncoder（来自category_encoders库）更稳，但需注意数据泄露风险——务必用cv折内均值或添加噪声
如何用 ColumnTransformer 安全接入大规模类别列？
核心是隔离处理逻辑，避免把类别列和数值列混在一起做标准化或 PCA。常见错误是写成 StandardScaler().fit_transform(X)，结果类别列被当成浮点数乱缩放。
立即学习“Python免费学习笔记（深入）”；
- 必须用
ColumnTransformer显式声明列类型：transformers=[('cat', OneHotEncoder(sparse_threshold=0.0), ['col_a', 'col_b']), ('num', StandardScaler(), ['col_x', 'col_y'])] - 传入的列名必须是原始 DataFrame 的列名，不能是位置索引（
[0,1]）——否则ColumnTransformer在 pipeline 中无法对齐新数据 - 如果类别列含缺失值，
OneHotEncoder(handle_unknown='ignore')是必须的，否则transform()时遇到训练期未见的新值直接报错ValueError: Found unknown categories
稀疏矩阵后续怎么喂给模型？
不是所有模型都“认得”稀疏矩阵。比如 sklearn.ensemble.GradientBoostingClassifier 内部会自动 densify，导致 OOM；而 lightgbm.LGBMClassifier 或 xgboost.XGBClassifier 原生支持 CSR/CSC，效率更高。
- 检查模型文档：搜索 “sparse input” 或看
fit()方法签名里X的类型注释 - 临时调试技巧：用
scipy.sparse.issparse(X_encoded)确认输出类型，再用X_encoded.toarray()[:2]快速看前两行是否符合预期（注意只用于调试，别在线上跑） - 真正的大规模场景（>100 万样本 × >5000 类别），考虑用
HashingVectorizer替代OneHotEncoder——它不保存映射表，固定输出维度，但会引入哈希冲突；适合流式或内存极端受限场景
最易被忽略的一点：类别列的内存占用主要不在编码过程，而在 OneHotEncoder 内部维护的 categories_ 属性——它存的是 Python list of numpy arrays，每个 array 存一个列的所有唯一值。1000 列 × 每列平均 1000 个字符串，轻松占几百 MB。上线部署前，务必用 joblib.dump(..., compress=3) 保存 encoder，并在加载后手动删掉 encoder.categories_（只要不调用 inverse_transform 就不影响预测）。
