featurehasher专为高基数类别特征设计，适用于用户id、设备型号、url路径等onehot易致维度爆炸的场景，具备无状态、低内存、高速度优势，但牺牲可解释性与逆变换能力。
FeatureHasher 适合什么场景？
它专为高基数类别特征设计，比如用户ID、设备型号、URL路径、城市名（超50个取值）等。当 OneHotEncoder 会导致特征列爆炸（如1000+维）、训练变慢、内存吃紧时，FeatureHasher 是一个无状态、低开销的替代方案。但它不保留可解释性——你无法查出“第3列对应哪个城市”，也不支持 inverse_transform。
n_features 设多少才不踩坑？
设太小会高频碰撞，模型学不到区分度；设太大又浪费空间，且默认 n_features=2**20（约100万维）对多数任务是过度的。实操建议：
- 从
n_features=2**18（262144）起步，观察训练速度与验证集效果波动 - 若数据量小（10万唯一值），可降到
2**16（65536），但需配合alternate_sign=True抵消冲突偏差 - 避免用
n_features=100这类极小值——冲突率可能超30%，输出矩阵接近全零 - 用
hasherd.toarray().sum()对同一输入连续两次transform，结果必须完全一致；否则说明环境 hash seed 不稳定（Python 3.3+ 默认开启 randomization）
input_type 和数据格式怎么配？
FeatureHasher 不接受 DataFrame 直接传入，只认两种格式：dict 列表或字符串列表。常见错误是直接喂 pd.Series 导致 TypeError: unhashable type: 'list'。
正确做法：
- 字符串场景（如城市名）：
fea_hs.transform(data['city'].tolist())，此时input_type='string' - 带权重的键值对（如
{'city': '北京', 'age_group': '30-39'}）：input_type='dict'，需先转成字典列表：[{'city': c, 'age_group': g} for c, g in zip(data['city'], data['age_group'])] - 单个样本含多个特征（如词性+token组合）：用生成器函数构造，避免一次性加载全量内存
和模型搭配要注意哪些隐性约束？
哈希后的稀疏矩阵默认含正负值（因 alternate_sign=True），这对某些模型是致命的：
-
SGDClassifier(loss='log_loss')要求非负输入，否则 sigmoid 易溢出 → 必须设alternate_sign=False -
sklearn.naive_bayes.MultinomialNB或chi2特征选择器也要求非负 → 同样禁用alternate_sign - 输出是
scipy.sparse.csr_matrix，别直接用.values或.to_numpy()转稠密——10万样本 × 26万维会 OOM - 线上部署时，不能靠 pickle 保存
FeatureHasher实例跨进程复用；必须统一 Python 环境 + 固定HASHSEED=0环境变量
最常被忽略的一点：哈希冲突不是 bug，而是设计前提。它靠符号抵消来缓解误差，所以输出均值趋近于0——这意味着你不能对哈希后特征做 min-max 归一化，也不能指望某列数值大小直接对应原始类别的“重要性”。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
