测试集准确率骤降主因常是未固定train_test_split的random_state，致数据划分随机、输入不稳定；小数据集尤甚。
测试集准确率骤降，大概率不是模型本身坏了，而是数据划分或评估方式出了问题——尤其当你没固定 train_test_split 的 random_state。
train_test_split 不设 random_state 就等于每次重抽样
随机森林本身稳定，但它的输入数据不稳定，结果就必然漂移。不设 random_state 时，train_test_split 每次调用都随机打乱并切分，小数据集（比如
- 现象：同一段代码跑三次，测试准确率分别是 0.83、0.71、0.64
- 验证方法：打印
y_test的类别分布，np.bincount(y_test)看是否每次都不一样 - 修复动作：强制加
random_state=42（任何整数都行，但必须固定） - 注意：仅固定模型的
random_state不够，train_test_split的也要设
测试集比例太小，统计噪声直接压垮评估结果
当 test_size=0.1 且总样本仅 300 条时，测试集才 30 个样本。错 3 个就是 10% 准确率损失——这不是模型变差，是评估不可靠。
- 安全下限：测试集至少 100 个样本（二分类）或每类 ≥ 30 个（多分类）
- 推荐做法：用
stratify=y保证训练/测试集中各类比例一致，避免某次切分后测试集缺少数类样本 - 更稳方案：改用交叉验证，
cross_val_score(model, X, y, cv=5)，绕过单次划分偏差
特征里混进了未来信息或未对齐的标签
准确率骤降有时根本不是泛化问题，而是“作弊”被发现：训练时用了测试阶段不可能拿到的字段（比如用「成交时间」预测「是否下单」），或者标签和特征没按行对齐。
立即学习“Python免费学习笔记（深入）”；
- 典型错误：pandas 合并数据时没设
reset_index(drop=True)，导致 X 和 y 行序错位 - 静默陷阱：特征中存在时间戳类字段（如
log_time），模型学到了时间先后顺序而非真实规律 - 排查动作：检查所有特征列是否在业务逻辑上「测试时可得」；用
X.index.equals(y.index)验证对齐 - 补救：删掉时间类字段，或转为滞后特征（如「过去7天平均点击量」）
真正要警惕的，不是准确率数字本身，而是它波动的幅度——如果两次运行差值超过 5%，优先查 train_test_split 和测试集大小，而不是急着调参或换模型。
