pd.get_dummies() 默认不识别 Categorical 结构，仅按底层值处理，故不保留 categories 顺序、不自动包含未出现类别，需手动 reindex 或改用 OneHotEncoder 确保一致性。
为什么 pd.get_dummies() 对 Categorical 列默认不生效？
直接对含 Categorical 类型的 DataFrame 调用 pd.get_dummies()，结果可能和预期不符：它会把整个分类列当做一个普通 object 列处理，生成带完整类别名的 dummy 列（如 color_Red、color_Blue），但不会自动利用 Categorical 的有序性或已定义的 categories 顺序，更不会跳过未出现的类别。
根本原因在于 pd.get_dummies() 默认不识别 Categorical 的结构，只看底层值。如果你希望保留原始 categories 定义（比如明确设定了 ['Low', 'Medium', 'High'] 且要求输出三列，哪怕某类在当前数据中没出现），就得手动干预。
- 用
pd.get_dummies(df, columns=['col'], prefix='col')是最简方式，但它不保证覆盖全部categories - 若需强制包含所有预设类别（包括缺失项），必须先用
df['col'].cat.reorder_categories(...)确保顺序，并配合dummy_na=False+ 后续reindex() -
Categorical列含NaN时，默认不生成col_nan列；加dummy_na=True才会额外加一列
如何让独热结果严格按 Categorical.categories 顺序排列？
默认 pd.get_dummies() 按照数据中首次出现的顺序生成列名，不是按 .categories 定义的逻辑顺序。这对建模很危险——训练集和预测集列序不一致会导致特征错位。
正确做法是：先提取目标列的 categories，再用 pd.get_dummies() 后显式 reindex()：
立即学习“Python免费学习笔记（深入）”；
cats = df['status'].cat.categories
dummies = pd.get_dummies(df['status'], prefix='status')
dummies = dummies.reindex(columns=[f'status_{c}' for c in cats], fill_value=0)
注意：reindex() 中的列名必须和 get_dummies() 实际生成的一致（即带 prefix），否则会全为 NaN；fill_value=0 确保缺失类别列补零而非 NaN。
安全 Python 代码沙箱：在隔离的沙箱中执行任意 Python 代码，预装 requests、NumPy、pandas 库。返回 stdout、stderr。
- 如果原始
Categorical是有序的（ordered=True），这个顺序也会被保留进列名顺序 - 不要依赖
sort_columns=True—— 它按字符串排序，和业务逻辑顺序无关 - 对多列同时处理时，需分别获取各自
categories并分别reindex
用 sklearn.preprocessing.OneHotEncoder 处理 Categorical 更可靠吗？
是的，尤其在生产 pipeline 中。相比 pd.get_dummies()，OneHotEncoder 显式支持 Categorical 输入，且能保存 fit 阶段的 categories_，确保 transform 时列数、顺序、缺失类别行为完全一致。
关键点：
- 传入前确保列是
Categorical类型（df[['col']].astype('category')） - 设置
sparse=False避免返回稀疏矩阵（Pandas 不友好） - 用
handle_unknown='ignore'可安全处理预测时出现的新类别（输出全零行） - 编码后需用
encoder.get_feature_names_out()获取列名，并转成 DataFrame
示例片段：
from sklearn.preprocessing import OneHotEncoder
enc = OneHotEncoder(sparse=False, handle_unknown='ignore')
X_cat = df[['grade']].astype('category')
encoded = enc.fit_transform(X_cat)
df_encoded = pd.DataFrame(encoded, columns=enc.get_feature_names_out(['grade']), index=df.index)
容易忽略的内存与 dtype 陷阱
Categorical 的初衷是节省内存，但独热编码后反而可能暴增——特别是高基数分类变量（如用户ID、商品SKU）。更隐蔽的问题是 dtype：默认 pd.get_dummies() 输出 uint8，而 OneHotEncoder 输出 float64。
- 若后续要接 scikit-learn 模型，
float64没问题；但若存 CSV 或传给某些 C 扩展库，uint8更省空间 - 用
pd.get_dummies(...).astype('uint8')可显式降级，但得确认没NaN（否则会变成float64） - 对含大量
NaN的Categorical列，dummy_na=True会额外增加一列，务必检查是否真需要区分“缺失”和“其他” - 用
df['col'].cat.remove_unused_categories()清理掉从未出现过的类别，避免无谓的 dummy 列
真正麻烦的不是怎么编，而是训练时用了 127 个类别，上线后某天突然冒出第 128 个——这时候 encoder 是否容错、列名是否可预测、dtype 是否兼容，全在那一刻见分晓。
