Apriori内存爆破主因是低min_support导致候选项集指数爆炸，应设max_len=3截断、按value_counts第95百分位设min_support；association_rules中frozenset需sorted转序列表示；lift>1.5兼顾业务价值，验证规则须回溯原始数据比对实际频次。
Apriori算法卡在min_support设太低，内存爆了怎么办
频繁项集数量随min_support下降呈指数级增长，不是“算得慢”，而是生成的候选项集把内存撑爆。尤其当数据有长事务（比如购物篮含50+商品）或高基数品类时，mlxtend.frequent_patterns.apriori默认会尝试生成所有2项集、3项集……直到撑不住。
- 先用
max_len=3硬性截断项集长度，避免生成无意义的长组合（实际业务中>3的商品组合解释性极差） -
use_colnames=True必须开，否则返回的是整数编码，后续association_rules会报KeyError - 真正要调的不是
min_support，而是先用pd.Series.value_counts()看单品支持度分布，把min_support设成略高于第95百分位数——既能过滤噪声，又不至于漏掉主流组合
为什么association_rules输出的antecedents全是frozenset，没法直接用
这是mlxtend为保证集合操作安全做的设计，但直接遍历frozenset会丢顺序，转list又可能破坏唯一性。真实场景里你要拿结果喂前端表格或写入数据库，得可读、可索引、可排序。
- 别用
list(rule)暴力转——frozenset无序，每次结果可能不同 - 统一用
sorted(list(rule))，确保同一规则每次导出顺序一致 - 如果字段要存数据库，用
'|'.join(sorted(list(rule)))转字符串；需要反查原始商品名，就提前建好id_to_name字典，别等输出后再映射 - 注意
antecedents和consequents都是frozenset，两个都得处理
从apriori输出到关联规则，metric='lift'和min_threshold=1.0到底在筛什么
lift不是置信度，是“买了A的人买B的概率”除以“随便一个人买B的概率”。lift > 1才说明A和B真有正向拉动，等于1就是独立事件，小于1反而负相关。但设min_threshold=1.0会保留大量lift≈1.001的弱规则，实际没业务价值。
- 业务上lift至少要>1.3才算有干预价值，电商常设
min_threshold=1.5 -
metric='confidence'容易被高频单品带偏（比如“牛奶→面包”置信度高，只是因为面包本身卖得多），必须搭配support一起看 - 别只盯着lift排序——加一列
df['support'] * df['lift']（叫“提升支持度”），兼顾发生频率和关联强度
频繁项集生成后，怎么快速验证某条规则是否合理
跑完得到一堆(A, B) → C，但业务同学第一反应往往是：“我们真观察到过这个组合吗？”——不能光靠数字，得回溯原始数据查证。
立即学习“Python免费学习笔记（深入）”；
- 用
df[ df['A']==1 & df['B']==1 & df['C']==1 ].shape[0]直接统计三者同时出现的行数，和support值比对（注意support是比例，要乘总行数） - 如果原始数据是事务列表（如
[['apple','banana'], ['banana','cherry']]），用any(set(['A','B']).issubset(x) for x in transactions)快速检查是否存在含A和B的事务 - 最易忽略的一点：确认你的one-hot编码没漏掉空事务——
apriori遇到全0行会静默跳过，但这些行本应参与分母计算，导致support虚高
频繁项集本质是计数游戏，所有参数都在和“分母怎么定”较劲。别迷信默认值，每次跑之前先df.sum().sum() / len(df)算下平均非零列数，心里才有底。
