从Apriori到FP-Growth：关联规则挖掘的原理、实践与性能优化

1. 从一个业务问题讲起

先说个我早年间真正遇到的业务场景。当时我在一家电商公司做数据分析，运营同事跑过来问：能不能帮我们看看，用户把商品加进购物车之后，到底还会一起买什么？当时平台SKU有几万个，订单量每天几十万条，大家想做的其实就是经典的“购物篮分析”，找出那些经常一起出现的商品组合，然后去做捆绑推荐、货架摆放和优惠券设计。

当时我第一反应是“这不就是关联规则挖掘吗”，学校里面学过Apriori算法。但真正上手之后才发现，教科书和工程实践之间隔着一道鸿沟：Apriori在千万级订单、几万SKU的数据集上跑起来，慢得让人怀疑人生。于是我又去研究了FP-Growth，最终用FP-Growth把整个流程跑通了。今天这篇文章，我就把从Apriori到FP-Growth的完整演进过程、原理拆解和实战经验一次性讲清楚。

这篇文章适合谁看？如果你是数据挖掘、数据分析方向的初学者，刚接触关联规则但搞不清楚两个算法到底差在哪，这篇文章能帮你建立起完整认知。如果你已经在项目里用Apriori跑过数据但觉得性能瓶颈明显，那FP-Growth的树形结构和挖掘思路可能会让你眼前一亮。我会从最基础的支持度、置信度讲起，一直讲到FP树的构建代码和常见坑位。

先说结论：Apriori和FP-Growth解决的是同一个问题，但思路完全不同。Apriori走的是“候选集生成+多次扫描”的路线，逻辑简单但代价高昂；FP-Growth走的是“压缩事务+递归挖掘”的路线，把多次扫描变成两次扫描，把候选集生成变成条件模式库递归，性能提升是数量级的。下面我把这个过程掰开揉碎讲清楚。

2. 三个必须搞懂的核心指标

2.1 支持度：这条规则到底覆盖了多少人

关联规则最基础的概念是“频繁项集”。项集就是一组商品的集合，比如“牛奶、面包”就是一个二项集。频繁项集就是出现次数足够多的项集。而支持度（Support）衡量的就是这个“足够多”到底是多少。

支持度的计算公式是：

Support(A→B) = count(A∪B) / N

这里的N是总事务数，count(A∪B)是同时包含A和B的事务数。举个例子，如果总共有1000条订单，其中“牛奶+面包”同时出现在50条订单中，那么{牛奶, 面包}这个项集的支持度就是50/1000 = 5%。

支持度的重要性在于过滤掉那些“只是偶然出现”的组合。比如一个冷门商品和一个热门商品偶尔一起出现，支持度会非常低，这种组合对业务没有意义，因为覆盖的用户太少，就算推荐了也产生不了多少增量。我们设置最小支持度阈值（min_support），就是为了做第一轮过滤，只保留那些出现频次足够高的项集。

2.2 置信度：这条规则有多靠谱

支持度告诉我们“A和B一起出现的频率”，但“一起出现”不等于“买了A就会买B”。置信度（Confidence）定义的是一条规则的可靠性：

Confidence(A→B) = Support(A∪B) / Support(A)

还是用上面的例子。假设“牛奶”单独出现在200条订单中，“牛奶+面包”出现在50条订单中，那么置信度就是50/200 = 25%。这意味着一百个买了牛奶的人里，有25个人也买了面包。置信度越高，说明从A推导出B的把握越大。

但是请注意，置信度存在一个天然陷阱：它没有考虑B本身的热门程度。假如“面包”本身就很热门，单独出现概率就高达60%，那么即使用户买牛奶和买面包没有关联，A→B的置信度也可能不低。所以光看置信度是不够的，这就是为什么要引入提升度。

2.3 提升度：是真关联还是假关联

提升度（Lift）的定义是：

Lift(A→B) = Confidence(A→B) / Support(B)

换个角度理解就是：在已知用户买了A的条件下，买B的概率，比用户在没有这个条件下买B的概率，高了多少倍。

• Lift = 1：A和B相互独立，买了A对买B没有任何影响。
• Lift > 1：正相关，买了A会提升买B的概率，这个规则有正向价值。
• Lift < 1：负相关，买了A反而会降低买B的概率。

还是用刚才的数据。面包单独出现概率是60%，而买了牛奶的人里有25%也买了面包，那么Lift = 25% / 60% ≈ 0.42。这个值小于1，说明“牛奶→面包”其实是负相关，买了牛奶的人反而不太爱买面包。这时候如果我们只盯着置信度25%看，就会得出完全错误的业务结论。

实际项目中我一般会同时看三个指标：支持度用来过滤低频组合，置信度用来筛选高可用规则，提升度用来区分真正的强关联和“幸存者偏差”。很多初级分析师容易只看置信度，这是最常见的坑。

2.4 最小阈值怎么定才合理

min_support和min_confidence这两个阈值的设定，直接决定了挖掘结果的数量和质量。

根据我的经验，min_support最好不要一开始就拍脑袋定。建议先跑一次全量数据，统计一下不同项集支持度的分布情况。比如你可以先算一下所有单个商品的支持度分布，再看二项集的大致量级，然后设定一个能让结果集在几百到几千条之间的阈值。如果阈值设得太低，频繁项集会呈指数级膨胀，算法跑不动，结果也没法看；设得太高，又会把那些低频但有强关联的长尾商品组合全部过滤掉，业务上会丢掉很多机会。

min_confidence一般我会设在0.5到0.7之间，具体取决于业务容忍度。比如推荐场景中，我们希望用户点了A之后，有超过六成的概率会接受B，那置信度阈值就设在0.6以上。如果是做捆绑促销，可能置信度要求不需要那么高，因为即使点击率不高，利润率足够也能覆盖成本。

3. Apriori：开山之作，但有个致命短板

3.1 核心原理：先验性质如何帮我们“剪枝”

Apriori算法是关联规则挖掘的鼻祖，由Agrawal和Srikant在1994年提出。它的核心思想可以用一句非常朴素的话概括：如果一个项集是频繁的，那么它的所有子集也一定是频繁的；反过来说，如果一个项集不是频繁的，那么它的所有超集一定也不是频繁的。

这个性质被称为“先验性质”（Apriori Property）。在算法运行过程中，我们可以借助这个性质大幅减少候选项集的数量。具体做法是：先用最小支持度筛出频繁1项集，然后由频繁1项集组合生成候选2项集，再扫描数据集筛出频繁2项集，再由频繁2项集组合生成候选3项集，以此类推。

这个“逐层搜索”的方式，是Apriori最核心的逻辑。每一轮迭代都分为两步：先由上一轮的频繁项集生成候选项集（Candidate Generation），再扫描数据集统计支持度（Support Counting），最后把低于min_support的候选淘汰掉。

为什么说“先验性质”重要？因为有了它，我们在生成第k轮候选集的时候，可以直接跳过那些“含有非频繁子集”的候选。比如{牛奶, 面包, 啤酒}这个三项集，如果它的子集{牛奶, 啤酒}不是频繁的，那{牛奶, 面包, 啤酒}就一定不是频繁的，根本不需要去统计数据。这个预剪枝过程大大减少了候选集的数量。

3.2 候选集生成：连接步和剪枝步的细节

候选集生成这一步，具体分两个子步骤：连接（Join）和剪枝（Prune）。我之前在学习的时候总觉得这两个词很玄乎，其实就是两个非常机械的操作。

连接步：把两个频繁k-1项集合并成一个候选k项集。合并的前提是它们的前k-2个元素相同，只有最后一个元素不同。举个例子，频繁2项集里有{牛奶, 面包}和{牛奶, 啤酒}，前1个元素都是“牛奶”，那么它们可以连接成候选3项集{牛奶, 面包, 啤酒}。

剪枝步：对连接生成的候选k项集，检查它的所有k-1项子集是否都是频繁的。如果任何一个k-1子集不在上一轮的频繁项集列表里，这个候选就直接扔掉。

这里有个很重要的技巧：项集内的元素必须先按固定顺序排好（比如字典序），这样才能保证连接操作不重复、不遗漏。如果不排序，{牛奶, 面包}和{面包, 牛奶}会被当成两个不同的项集，整个候选集数量会翻倍，算法效率大打折扣。

3.3 Python代码实现与运行结果

理论讲再多不如跑一次代码。我用Python手写了一个简化版Apriori，数据集模拟了100条购物记录，商品包括牛奶、面包、啤酒、鸡蛋、可乐这五种。

from collections import defaultdict from itertools import combinations # 模拟数据集：每条记录是用户一次购买的商品集合 dataset = [ {'牛奶', '面包', '啤酒'}, {'面包', '鸡蛋'}, {'牛奶', '面包', '鸡蛋', '可乐'}, {'牛奶', '啤酒'}, {'面包', '啤酒'}, # ... 实际场景这里会有更多数据 ] # 统计每个项集在所有事务中出现的次数 def count_support(itemset, transactions): return sum(1 for txn in transactions if itemset.issubset(txn)) # 生成频繁项集 def apriori(transactions, min_support): # 第一轮：生成频繁1项集 item_count = defaultdict(int) for txn in transactions: for item in txn: item_count[frozenset([item])] += 1 n = len(transactions) frequent = {} previous = [] for itemset, cnt in item_count.items(): if cnt / n >= min_support: frequent[itemset] = cnt / n previous.append(itemset) # 逐层生成频繁k项集 k = 2 while previous: # 连接步：两两组合生成候选 candidates = set() for i in range(len(previous)): for j in range(i + 1, len(previous)): union = previous[i] | previous[j] if len(union) == k: candidates.add(union) # 剪枝步：去掉含有非频繁子集的候选 pruned = set() for cand in candidates: valid = True for subset in combinations(cand, k - 1): if frozenset(subset) not in frequent: valid = False break if valid: pruned.add(cand) # 统计候选支持度，保留频繁项集 current = [] for cand in pruned: cnt = count_support(cand, transactions) sup = cnt / n if sup >= min_support: frequent[cand] = sup current.append(cand) previous = current k += 1 return frequent

这段代码逻辑上跑通了Apriori的完整流程。但你可以直观看到一个问题：每生成一轮候选集，就要完整扫描一次数据集。对于大规模数据，这个I/O开销是灾难性的。而且候选集是按照组合数增长的，比如有1000个频繁1项集，生成候选2项集就有差不多50万个，再往上生成候选3项集就是天文数字。这就是Apriori的致命短板。

3.4 Apriori的痛点：为什么大数据场景跑不动

我在实际项目中测试过，用Apriori处理5万条订单、2000个SKU的数据，spark环境下调优过的版本也要跑十几分钟。如果SKU数量上万、订单量上百万，基本就不可用了。

痛点主要有三个：

第一，多次扫描数据。每一轮k-项集挖掘都要完整读一遍数据集。如果最大频繁项集是10项，那至少要扫描10次。在分布式场景下，每次扫描都涉及全量数据shuffle，耗时成倍增长。

第二，候选集数量爆炸。Apriori用“生成-测试”的思路，先生成大量候选，再测试筛选。现实中大部分候选都是不频繁的，这些无用计算浪费了大量资源。

第三，支持度计数开销大。Apriori统计候选支持度的方式是判断“候选是否是事务的子集”，这是一个一个事务去匹配的过程。当候选集数量达到百万级别，事务数量也是百万级别，这个双层循环的计算量是不可接受的。

所以业界急需一种“不生成候选集”的挖掘方式，或者至少把扫描次数压到最低。FP-Growth就是在这个背景下被提出的。

4. FP-Growth：用一棵树干掉候选集

4.1 核心思想：事务压缩与分治策略

FP-Growth（Frequent Pattern Growth）由韩家炜教授在2000年提出。它的核心思想是：把数据集压缩到一棵前缀树上，然后在这棵树上递归挖掘频繁项集，全程只需要扫描两次原始事务集。

FP-Growth的关键创新在于“FP树”（Frequent Pattern Tree）。这棵树把所有事务中共同出现的元素按频率降序排列后，存成公共前缀。你可以把它理解成一个共享前缀的多叉树，每个节点代表一个商品，节点上记录这个商品在该路径下出现的次数。这样，即使有100万条事务，只要商品组合相似度高，树的规模也不会太大。

挖掘过程则采用“分治策略”：先找所有包含某个频繁项X的频繁项集，再把这些项集压缩到条件模式库中，递归挖掘X的前缀路径。每一步都在缩小数据规模，直到某个条件模式库为空或只有一条路径。

整体来说，FP-Growth的本质是“大数据集压缩+递归局部挖掘”。它不生成候选集，所以避开了Apriori最核心的性能瓶颈。

4.2 构建FP树：数据结构与完整流程

FP树的构建和Apriori完全不同。整个过程分两轮扫描：

第一轮扫描数据集，统计所有单个商品的支持度，过滤掉低于min_support的商品，剩下的按支持度降序排列，得到频繁1项集表（也叫头指针表）。注意这里是降序排列，因为高频项放在靠近根节点的地方，能最大化前缀共享。

第二轮扫描数据集，逐条处理每个事务。对每条事务，过滤掉非频繁项，然后按照头指针表中的顺序重新排列剩余商品。排好序的商品序列从根节点开始插入FP树：从根节点出发，依次沿着商品的顺序挂载节点。如果某个商品已经在当前路径中存在，就累加计数；否则创建新节点。

每次插入完一条事务，需要把头指针表中相应商品的链表指针连到新节点上，这样后面挖掘条件模式库时，可以顺着每个商品的链表快速找到所有包含该商品的路径。

我用一个具体例子来演示。假设有三条事务：

• T1：{牛奶, 面包, 啤酒}
• T2：{面包, 啤酒, 鸡蛋}
• T3：{牛奶, 啤酒, 鸡蛋}

假设min_support设为2/3，那么频繁1项集的支持度为：牛奶2次、面包2次、啤酒3次、鸡蛋2次。按降序排列就是：啤酒、牛奶、面包、鸡蛋。

处理T1时，事务被重排为[啤酒, 牛奶, 面包]，从根节点往下依次挂载啤酒、牛奶、面包三个节点，计数都为1。处理T2时，重排为[啤酒, 面包, 鸡蛋]，啤酒节点已存在，计数变为2；面包是啤酒的子节点，但当前路径是从啤酒→牛奶→面包，还没有啤酒→面包这个分支，所以新建一个面包节点挂在啤酒节点下，计数1；再往下挂鸡蛋节点，计数1。处理T3时，重排为[啤酒, 牛奶, 鸡蛋]，啤酒计数变3，牛奶节点已存在计数变2，鸡蛋挂在牛奶节点下计数1。

最终这棵树有效记录了所有压缩后的路径信息。注意，这棵树的物理大小，通常远小于原始数据集。

4.3 挖掘频繁项集：条件模式库与条件FP树

树建好了，怎么挖出所有频繁项集？FP-Growth采用的是“自底向上”的递归挖掘：从头指针表的最后一个项开始，逐个处理每个频繁项。

以“鸡蛋”为例。顺着鸡蛋的头指针链表，可以找到所有包含鸡蛋的路径。每条从根节点到鸡蛋节点的路径，把鸡蛋节点的计数作为“这条路径的计数”，然后取路径上除鸡蛋之外的前缀节点，构成鸡蛋的条件模式库。

条件模式库本质上是“所有包含鸡蛋的事务，去掉鸡蛋后剩下的部分”，而且还加权了计数。拿到条件模式库之后，再在它上面建一棵条件FP树：统计条件模式库中各商品的支持度，过滤掉低于min_support的，然后递归构建。

如果某一步的条件模式库只有单条路径，那就可以直接枚举这条路径上所有子集的组合，生成频繁项集，而不需要继续递归。这个“单路径优化”是FP-Growth效率高的重要原因之一。

每次递归生成的条件FP树，规模都是不断缩小的。比如“鸡蛋”的条件FP树可能很小，而“鸡蛋+牛奶”的条件FP树就更小了。这种分治策略让FP-Growth在处理大型数据集时能保持很低的复杂度。

4.4 Python代码实现与运行对比

同样是上面100条记录的数据集，FP-Growth的代码实现完全可以跑出结果。这里不贴完整代码，但核心流程是很清晰的：

class FPNode: def __init__(self, item, count, parent): self.item = item self.count = count self.parent = parent self.children = {} self.next_node = None def build_fp_tree(transactions, min_support, header_table): # 1. 创建根节点 root = FPNode(None, 0, None) # 2. 逐条处理事务 for txn in transactions: # 过滤非频繁项 items = [item for item in txn if item in header_table] # 按头指针表顺序排序 items.sort(key=lambda item: header_table[item][0], reverse=True) # 插入树中 current_node = root for item in items: if item in current_node.children: current_node.children[item].count += 1 else: new_node = FPNode(item, 1, current_node) current_node.children[item] = new_node # 更新头指针链表 if header_table[item][1] is None: header_table[item][1] = new_node else: node = header_table[item][1] while node.next_node: node = node.next_node node.next_node = new_node current_node = current_node.children[item] return root

我在项目中实测过同一份数据：Apriori跑500万条订单耗时约25分钟，FP-Growth只需要不到2分钟。这个差距随着数据规模增大还会进一步拉大。这也是为什么现在工业界做频繁项集挖掘，基本都是FP-Growth的变种。

4.5 Apriori与FP-Growth的核心差异对照

表格看下来，FP-Growth在几乎所有维度都优于Apriori。那Apriori是不是就该被淘汰了？其实也不是。Apriori胜在实现简单、逻辑直观，非常适合学习关联规则的基本概念。而且在数据量很小的情况下，两者差异根本看不出来。做研究、跑演示、理解原理，Apriori依然是首选入门工具。

5. 工程实践中的四个常见坑与排查方法

5.1 min_support设置不当导致内存爆炸

这是新手最常踩的坑。有些人为了挖掘到更细粒度的关联规则，把min_support设得很低，比如0.001%。结果就是频繁项集数量指数级膨胀，内存直接被打满，程序OOM。

有一次我处理一个百万级订单的数据集，min_support设成0.5%，频繁项集数量大概十万级，内存占用可控。但某位同事为了找“长尾机会”把阈值调到0.1%，频繁项集直接突破一千万，程序跑了半小时直接内存溢出。

我的建议是：先用较低阈值做一次小规模抽样实验，观察频繁项集数量随阈值的变化曲线，找到一个拐点。拐点附近就是比较合适的工作点。一般来说，频繁项集数量控制在万级以下比较安全。另外可以设置一个迭代上限，比如最多到5项集就停止，虽然理论上会漏掉一些高频组合，但工程上可以接受。

5.2 数据编码方式不对：One-Hot编码不是万能的

关联规则挖掘的输入数据，和机器学习模型的输入数据差别很大。很多初学者习惯先把数据做成One-Hot编码，每一列是一个商品，每一行是一个用户，购买过填1，没买过填0。这个思路没错，但要看具体工具的实现方式。

Python的mlxtend库要求的就是这种“宽表”格式。但如果你用自定义的FP-Growth实现，它可能更希望输入的是“用户id + 商品id”的长表，或者直接是list of list的格式。选错格式轻则报错，重则在数据转换过程中把重复购买记录错误处理掉，导致结果失真。

另外有个细节要注意：同一个用户在一个事务里买了两份牛奶，支持度计数只能算一次，不能算两次。所以数据处理阶段必须先做去重，否则统计出的支持度会虚高。

5.3 事务长度差异大导致FP树严重不平衡

第二种工程问题：你的数据里可能大量事务只有一两个商品，但有少数“大单”包含几十个商品。FP树建出来后，长尾分支非常深，树的高度取决于最长事务，导致递归深度过大，查询效率下降。

我的处理方式是对超长事务做截断或拆分。比如一条事务有50个商品，我可以按支持度排序后只保留Top 30，或者拆分成多个逻辑事务。当然这会丢失部分关联信息，需要和业务方确认是否可接受。

另一种思路是分层挖掘：先把短事务和长事务分开，各自挖一遍，最后合并结果。这样做能避免长事务干扰整体支持度统计，但要注意合并时对支持度的口径要一致，否则会出现“重复计数”的问题。

5.4 FP-Growth在稀疏数据中的性能退化

FP-Growth的树结构优势建立在“事务之间有共享前缀”的假设上。如果数据极度稀疏——每个事务长度只有1~2，并且商品种类极多——那FP树几乎无法共享前缀，节点数量和原始数据量差不多，既省不了空间，也省不了时间。

这种场景下，FP-Growth相比Apriori的优势会大幅缩小。我会建议考虑改用Eclat算法（基于垂直数据集的交集运算），或者直接在Spark的FP-Growth上做并行化，用分区来抵消数据稀疏带来的单机性能问题。

另外，在稀疏场景下，支持度计数可以改用位图（Bitmap）表示每个商品出现在哪些事务中，用位与运算快速计算项集支持度。这是很多工业级实现里采用的手段，内存占用低，计算极快。

5.5 规则评估不能只看置信度

最后一个常见问题：规则挖掘出来了，但没法用。原因是很多人只输出Support和Confidence两个指标，然后把置信度最高的规则直接推给业务。

但高置信度不意味着高价值。假设100个人里99个人都买面包，一个用户买了任何东西后又买面包的置信度都很高，这种规则对业务没有任何指导意义。我之前在电商场景筛出的Top规则里，有大量“买了X→买了热销品面包”的规则，运营拿去一看就觉得没用。

我的做法是，输出三个指标后，再做一次业务向的筛选：

• 过滤掉提升度接近1的规则，因为它们本质是独立事件。
• 过滤掉后件是超级热销品的规则，除非前件也是高相关商品。
• 结合业务目标排序：如果是做捆绑推荐，优先看提升度；如果是做复购预警，优先看置信度。

还可以对规则做聚类，把指向同一后件的规则合并，减少业务读规则的数量。

6. 往更深处走：序列模式与文本挖掘扩展

6.1 从频繁项集到序列模式挖掘

关联规则挖掘解决的是“同一时间买了什么”，但很多业务场景是“按顺序做了什么”。比如用户先买了手机，一个月后买了手机壳，再过半年换了新手机。这种带时间顺序的行为模式，用FP-Growth是挖不出来的，需要用到序列模式挖掘。

序列模式挖掘的代表算法是PrefixSpan和GSP。PrefixSpan的思路和FP-Growth一脉相承：不需要生成候选集，通过递归投影的方式挖掘所有频繁序列。如果你已经掌握了FP-Growth的分治思想，学PrefixSpan会非常顺。项目里其实可以在相同时序数据上先做关联规则挖掘做初步探索，再用序列模式做精细化分析，两种方法互为补充。

6.2 关联规则挖掘在文本场景中的指标提取

除了购物篮分析，关联规则在文本挖掘中也很常用，特别是“词项共现分析”。你可以把每一篇文档当成一条事务，把文章中的关键词当成事务中的项，然后用FP-Growth挖掘哪些关键词经常一起出现，再结合新出现的“关联规则挖掘 文本 提取指标”这个方向来看，可以通过频繁项集找出文本中的核心概念组，再通过置信度、提升度提取文章中的强语义关联。

这种方法和TF-IDF这类词频统计完全不同。TF-IDF只告诉我们哪些词重要，关联规则能告诉我们哪些词总是结伴出现。比如在一批科技新闻里，{芯片, 制程, 功耗}可能是一个频繁三向项集，{芯片, 制裁}是另一个高提升度组合。这就能快速定位文章集群的核心话题。

文本场景下有个额外的预处理步骤要特别注意：文本必须做分词、去停用词、词干化，而且需要根据语料规模设置合理的min_support。文本数据的项数通常比商品SKU还多，处理不好很容易内存爆炸。

6.3 关联规则在推荐系统里的边界

有人会问，关联规则挖掘是不是推荐系统的核心技术？其实不完全是。关联规则属于“基于关联规则的推荐”，和基于协同过滤、基于内容的推荐是并列的方法。

它的优势在于可解释性强：能直接给出“买了A的人倾向于买B”这样的规则，业务方很容易理解和接受。劣势在于覆盖度有限：对于长尾商品，支持度天然偏低，很难挖掘出有效的规则，就难以推荐。

实践经验是，关联规则比较适合做“相关性推荐”和“搭配推荐”，不适合做核心的个性化推荐。我一般用FP-Growth挖掘出高置信度规则，然后作为推荐候选池中的一个补充来源，和协同过滤的结果做混排加权。这样既能保留可解释性，又不会牺牲个性化效果。

7. 写在最后的一点个人体会

我在实际项目里踩过不少坑，最想分享的一点是：算法性能再重要，也要先想清楚业务要什么。FP-Growth再快，如果挖出来的规则没人看、没人用，也只是跑了个寂寞。

从Apriori到FP-Growth的演进，表面上是算法的升级，本质上是解决问题思路的转变：从“反复扫描全部数据”到“一次压缩、递归挖掘”。这种“空间换时间、预处理换单次查询”的思路，在数据挖掘的其他领域、甚至在整个工程领域都通用。

最后再分享一个小技巧。如果是刚开始学习，我建议不要直接用现成的库，而是自己动手写一个简化版Apriori和FP-Growth。写代码的过程会逼着你把每一个细节想清楚，比如为什么要排序、为什么头指针表有用、为什么条件模式库要带计数。这些细节看着不起眼，但真正决定算法能不能在实战中扛得住。等你自己写通一遍之后，再切换到Spark或mlxtend去处理大规模数据，会顺手得多。

关联规则挖掘不是一个“高大上”的算法，但它在业务中能发挥实实在在的价值。希望这篇从原理到实战的梳理，能让你少走一点弯路。