必须先标准化再PCA，n_components应设方差比例（如0.95）而非固定整数；否则量纲差异会导致主成分被高数值特征主导，降维失效且模型性能下降。
直接说结论：不能跳过标准化，n_components 别硬设整数，优先用方差比例（如 0.95）；否则降维后数据可能失效，模型效果反而更差。
为什么必须先 StandardScaler 再 fit PCA
上百维业务指标（比如用户行为埋点、金融风控字段、IoT设备时序统计量）通常量纲差异极大：有的是点击次数（0–100），有的是停留时长（毫秒级）、有的是金额（万元级）。PCA 找的是“方差最大方向”，而原始方差完全被数值大的特征主导——比如“年交易总额”方差可能是“是否登录过App”的一万倍，后者哪怕业务意义再强，也会被忽略。
标准化把每个特征缩放到均值为 0、标准差为 1，让 PCA 真正基于结构相关性而非数值尺度做主成分排序。
- 不标准化 →
pca.explained_variance_ratio_偏斜严重，前几个主成分几乎全由高量纲字段贡献 - 标准化后 → 主成分反映的是原始特征间的协方差结构，才具备可解释性和稳定性
- scikit-learn 的
PCA不内置标准化，必须显式用StandardScaler预处理
n_components=0.95 比 n_components=10 更可靠
面对上百维业务指标，你根本不知道该保留多少个主成分。硬设 n_components=10 可能只保留了 60% 方差，信息损失太大；设 20 又可能混入大量噪声，没解决维度灾难。
立即学习“Python免费学习笔记（深入）”；
用方差比例更务实：n_components=0.95 表示“保留至少 95% 的原始总方差”，它会自动算出需要几个主成分（比如从 127 维压缩到 18 维），且这个数字在不同业务数据集间有可比性。
- 查看实际保留维度：
pca.n_components_（拟合后是 int 值，不是你传进去的 0.95） - 检查累计方差：
np.cumsum(pca.explained_variance_ratio_)，确认第 18 个值 ≥ 0.95 - 避免用
'mle'：它依赖数据分布假设，在真实业务数据（常含异常值、偏态）上容易低估维度
fit_transform 和 transform 必须用同一 scaler + pca 实例
线上部署或分批处理时，最容易踩的坑是：训练时用一个 StandardScaler 和 PCA，预测时却重新实例化、单独调用 scaler.transform(X_new) 再 pca.transform(X_new)——这会导致中心化参数不一致，结果错乱。
- 正确做法：保存整个 pipeline（推荐用
joblib.dump存scaler和pca两个对象） - 或者封装成函数，确保每次新数据都走完整流程：
scaler.transform → pca.transform - 特别注意：
pca.fit_transform(X_train)内部会用训练集均值/标准差中心化，但pca.transform(X_test)不会再中心化——所以必须先用同一个scaler处理测试集
whiten=True 在业务场景中多数时候没必要
whiten=True 会让每个主成分方差归一（即白化），听起来“更干净”，但实际业务中往往适得其反：
- 白化放大噪声：当原始数据信噪比不高（如埋点漏报、设备采样误差），白化会等权对待所有主成分，把低方差噪声成分也抬到和信号一样强度
- 破坏可解释性：白化后的主成分不再正交于原始坐标轴，无法回溯哪个原始指标贡献大
- 影响下游模型：随机森林、XGBoost 对输入尺度不敏感，但白化后特征范围变窄，可能让树分裂点选择变粗糙
- 除非后续要接对尺度敏感的模型（如 SVM with RBF kernel），否则保持默认
whiten=False
真正关键的不是“降到几维”，而是“降维后各主成分能否稳定对应业务逻辑”。建议在降维后，用 pca.components_ 查看每个主成分在原始 127 个指标上的权重，挑出前 3 个主成分，人工核对权重最高的几个原始字段——如果第一主成分里全是“登录次数”“页面停留”“点击率”，那说明它确实在捕获用户活跃度；如果混着“设备ID哈希值”“时间戳毫秒部分”，就要回头查数据清洗是否漏了非业务字段。
