StandardScaler默认不支持稀疏矩阵输入，会因true_divide操作报错；需设with_mean=False仅缩放，或改用MaxAbsScaler；线性模型如LogisticRegression需指定兼容稀疏的solver。
稀疏矩阵输入不被StandardScaler直接支持，会报错TypeError: No loop matching the specified signature and casting was found for ufunc true_divide
这是因为StandardScaler默认尝试对整个数组做逐元素除法，而scipy.sparse矩阵（如csr_matrix）不支持该操作。直接传入稀疏矩阵会崩溃，不是数据有问题，是预处理工具没选对。
- 必须改用
StandardScaler(with_mean=False)——关掉中心化（即不减均值），因为稀疏矩阵无法高效存储和计算均值；只保留缩放（除以标准差），该操作在稀疏结构下可安全进行 - 若业务上必须中心化（比如某些模型对零均值敏感），得先转稠密再处理，但仅限小规模数据，否则
MemoryError -
MinMaxScaler和RobustScaler同样不兼容稀疏输入，需同样设置with_mean=False或换用sklearn.preprocessing.MaxAbsScaler（它原生支持稀疏，且不依赖均值）
用TfidfVectorizer生成的csr_matrix如何安全喂给LogisticRegression或SVM？
好消息：这些线性模型（包括LinearSVC、SGDClassifier）内部已适配稀疏输入，无需转换。坏消息：如果中间插了不兼容的步骤（比如误用PCA），整个流程就断了。
- 确认向量化器输出类型：
type(X_train)应为scipy.sparse.csr_matrix或csc_matrix，不是numpy.ndarray - 避免无意识“致密化”：
X_train.toarray()、np.array(X_train)、甚至pandas.DataFrame(X_train)都会触发内存爆炸 -
LogisticRegression默认使用solver='lbfgs'，它不支持稀疏输入；必须显式设为solver='liblinear'（小数据）或'saga'（大数据，支持L1/L2混合正则）
CountVectorizer + TfidfTransformer组合 vs 直接用TfidfVectorizer，对稀疏性有影响吗？
没有本质区别，二者都产出csr_matrix。但组合写法容易在中间环节意外转成稠密——比如调用TfidfTransformer.fit_transform(X).A（.A强制转numpy array）。
- 统一推荐用
TfidfVectorizer，它把分词、计数、TF-IDF加权封装在一起，底层全程保持稀疏 - 若需单独控制停用词或ngram_range，仍可通过
TfidfVectorizer参数实现，不必拆开 - 警惕
fit_transform返回后立刻调用.todense()或.toarray()——这是线上服务OOM的常见源头
训练完模型，保存稀疏权重时为什么joblib.dump比pickle更稳妥？
joblib对NumPy数组和scipy稀疏矩阵做了专门优化，序列化时能保留稀疏结构；而原生pickle可能把csr_matrix存成低效格式，加载后变成稠密或损坏索引。
立即学习“Python免费学习笔记（深入）”；
- 始终用
joblib.dump(model, 'model.joblib')，别用pickle.dump - 验证是否真稀疏：
joblib.load('model.joblib').coef_返回的仍是csr_matrix，而非numpy.ndarray - 部署时若用Flask/FastAPI，加载模型后务必检查
isinstance(model.coef_, scipy.sparse.csr_matrix)，防止静默退化
高维稀疏数据真正的麻烦不在算法本身，而在每一步不经意的“转稠密”操作——它不会立刻报错，但会在10万行样本+10万特征时突然卡死或耗尽内存。
