企业官网建设流程全解析

简介：这是一份基于Java的Apriori关联规则挖掘算法完整工程源码，面向数据挖掘学习者与算法实现初学者，覆盖频繁项集生成、候选集剪枝、支持度与置信度计算等核心流程，可直接用于交易数据关联分析与市场篮分析。压缩包约550KB，共23个文件，包含8个Java源文件与对应8个class编译文件，另有4个不同规模（1000、5000、20000、75000条记录）的CSV测试数据以及Eclipse工程配置，目录结构清晰，便于导入IDE直接运行调试。工程按标准Apriori步骤组织，从项集生成、候选集连接、支持度计数到剪枝迭代均有完整实现，附带的多组CSV文件可供测试或结果对照，便于理解算法在不同规模数据下的运行效果。目前已有2336人学习下载，适合希望系统掌握算法原理、动手验证及在此基础上进一步优化实现的研究者与开发者。

1. 关联规则挖掘的起点：Apriori 算法在做一件什么事

关联规则挖掘这几年在电商推荐和用户行为分析里被反复提起，Apriori 算法作为其中最经典的实现，思路却意外地朴素：给你一张订单表，它负责找出“买了 A 的顾客，同时也倾向于买 B”这样的规律。我刚入行时接手过一个小需求——从半年销售数据里找搭配售卖的组合，当时直接套了一个开源库跑完，结果输出几百条规则，运营一条都没用上。后来把 Apriori 从底层自己实现了一遍，才明白问题不在算法，而在我根本不懂阈值怎么设、规则怎么解读。

这篇笔记面向两类人：想搞懂关联规则挖掘原理、准备面试或做课程设计的同学，以及需要在真实业务里落地 Apriori、但被海量候选集和一堆无效规则折磨的从业者。我会从最核心的支持度、置信度、提升度讲起，手写一个完整的 Python 实现，再把参数调优和常见的坑挨个拆开。读完你至少能自己跑出一份能解释、能交付的规则表，而不是只停留在调库出结果的黑匣子状态。

2. 三个指标与先验剪枝：Apriori 靠什么减少无用计算

2.1 支持度、置信度、提升度分别管什么

做关联规则挖掘，最先要过的是三个指标，缺一个都会导致结果失真。第一个是支持度（Support），公式是同时包含 X 和 Y 的事务数占总事务数的比例。它衡量的是“这个组合本身够不够常见”。比如有 10000 条订单，其中 200 条同时包含“牛奶”和“面包”，那支持度就是 2%。支持度太低意味着这个规则只是少数人的偶然行为，推给所有人没有意义。

第二个是置信度（Confidence），公式是同时包含 X 和 Y 的事务数除以包含 X 的事务数，也就是条件概率 P(Y|X)。它回答的问题是：一个顾客已经买了 X，他有多大可能再买 Y。置信度高代表“买了 X 大概率会买 Y”，但这里藏着一个统计陷阱，后面我会专门讲。

第三个是提升度（Lift），公式是 P(XY) 除以 P(X)P(Y)。它比较的是“实际同时购买的概率”和“假设 X 与 Y 完全独立时同时购买的概率”。提升度大于 1 说明 X 的出现对 Y 有正向拉动作用；小于 1 说明反而是负向关联；等于 1 则两者独立。业务里真正值得推的规则，提升度至少要明显大于 1，最好能到 1.5 以上。

这三个指标的关系，我总结成一套落地判断逻辑：先用支持度卡掉长尾组合，再用置信度保证规则的命中率，最后用提升度排除“热门商品互相抱团”的假象。只看其中任何一个指标，都会产生误导。举例来说，牛奶和面包都是高频单品，同时出现在很多订单里，置信度可能很高，但提升度可能只有 1.03，说明这个规则并没有太多增量价值，顾客只是顺手一起买而已。

2.2 先验性质与逐层搜索：候选集如何缩水

Apriori 算法真正厉害的地方不是算支持度，而是剪枝。它基于一个很直观的先验性质：一个频繁项集的任意非空子集，也一定是频繁项集。反过来想就是，如果某个 2-项集“牛奶、面包”的支持度连最小阈值都达不到，那么任何包含它的 3-项集“牛奶、面包、鸡蛋”的支持度只会更低，根本没资格成为频繁项集。

这条性质让算法可以采用逐层搜索策略：先从所有单品里筛出频繁 1-项集，再用这些频繁 1-项集拼出候选 2-项集，而不是对两两组合的全集做扫描。以此类推，生成候选 3-项集时，只从频繁 2-项集里做连接操作。每一步都先用先验性质剪掉一大批不可能的组合，再去扫描事务数据库做支持度验证。

我用一个小例子说明剪枝的效果。假设有 100 个单品，如果暴力计算所有 2-项集组合，数量是 C(100,2)=4950 个；但经过频繁 1-项集过滤之后，假设只有 30 个单品达标，候选 2-项集就只剩 C(30,2)=435 个。从 4950 到 435，直接少了一个数量级。到 3-项集这个差距还会继续扩大，这正是 Apriori 能在十几年前硬件条件下跑起来的根本原因。

实现上要注意一个细节：频繁项集的表示最好用不可变集合（frozenset），这样既能放进另一个集合里去重，又能作为字典的键做支持度计数。用 Python 里的 list 就不行，因为它是可变对象、不可哈希。这个数据结构的选择直接决定了后续代码的简洁程度，很多初学者在这上面翻车，就是因为在集合里塞了 list，运行时报错不知道去哪查。

2.3 什么时候选 Apriori，什么时候该换 FP-Growth

Apriori 不是万能的，它的性能瓶颈很清楚：每一轮生成候选集都要做集合连接，每一轮支持度计数都要重新扫描事务数据库。对几万条订单、几十个单品的场景，跑完整个流程在秒级，完全够用；但数据量到百万级订单、上千个单品维度时，每轮全表扫描的开销会让人难以忍受。

我自己的经验边界是：事务数在十万以下、单品数在两百以内，Apriori 可以用得很舒服；超过这个量级，就要开始考虑 FP-Growth——它把事务压缩到一棵 FP 树里，只需要扫描两遍数据库，不再反复生成候选集。但 FP-Growth 的实现复杂度更高，调起来也没有 Apriori 直观。

还有一个容易忽略的因素是数据的稠密程度。如果每条订单平均包含几十甚至上百个商品，频繁项集的组合数会爆炸式增长，这时候 Apriori 的候选集数量会远远大于稀疏数据。反过来，如果订单平均只有两三件商品，频繁项集本身就少，Apriori 反而很轻松。所以选型时可以先把订单平均商品数这个值统计出来做预判，不要一上来就拍板。

3. 用 Python 从零实现 Apriori：交易表到频繁项集

3.1 数据准备：订单表如何转成集合列表

Apriori 的输入是事务数据集，每个事务就是一个订单里的商品集合。真实业务里拿到的往往是明细行表，比如订单号加商品名，需要先聚合一下。我一般会把数据清洗成 Python 的 list of frozenset，一行为一个订单。这里先做一个模拟数据集，格式和你从 CSV 读出来之后聚合的结果是一致的。

import csv from collections import Counter def load_transactions(csv_path): """从订单明细 CSV 加载事务数据。 假设 CSV 有两列：order_id, item_name，同一订单多行。 """ order_items = {} with open(csv_path, 'r', encoding='utf-8') as f: reader = csv.reader(f) header = next(reader) # 跳过表头 for order_id, item_name in reader: if order_id not in order_items: order_items[order_id] = set() order_items[order_id].add(item_name) # 同一订单内去重 return [frozenset(items) for items in order_items.values()] if __name__ == '__main__': transactions = load_transactions('orders.csv') print(f'加载了 {len(transactions)} 个订单') avg_items = sum(len(t) for t in transactions) / len(transactions) print(f'平均每单包含 {avg_items:.2f} 件商品')

这段代码的关键在于用订单号做分组，再用 set 天然去重。同一个顾客在同一个订单里买了两件牛奶，只算一个“牛奶”项；如果你关心的是“两件一起买”的行为还是“买过这个商品”的行为，这里要首先想清楚。默认做法是去重，因为关联规则讨论的是商品组合的共现关系，而不是数量关系。平均商品数这个统计很重要，它直接决定后续候选集的规模。

代码里用 frozenset 而不是 set 作为返回值，原因前面提过：后面要把事务喂给算法做集合运算，还会把频繁项集放进另一个集合去重，frozenset 可哈希，才能当集合元素和字典键。如果返回的是 set，后面大概率会遇到TypeError: unhashable type: 'set'，这是初学者踩得最多的一个错误。加载完数据，下一步就可以写核心算法了。

3.2 候选集生成与支持度计数：核心循环

Apriori 主流程分两步：从频繁 k-1 项集生成候选 k-项集，然后扫描全部事务计算候选集的支持度，筛掉不达标的。这里给出完整的实现，包括两个辅助函数和一个主函数。

def generate_candidates(freq_sets, k): """从频繁 (k-1)-项集生成候选 k-项集。 freq_sets: 频繁项集的列表，每个元素是 frozenset。 k: 目标项集大小。 """ candidates = set() for a in freq_sets: for b in freq_sets: # 取并集，只保留大小为 k 的组合，实现自连接 union = a | b if len(union) == k: candidates.add(union) return candidates def filter_by_support(candidates, transactions, min_support, n): """统计候选集在每个事务中出现与否，保留支持度达标的项集。""" count = Counter() for t in transactions: for c in candidates: if c.issubset(t): count[c] += 1 # 支持度 = 包含该组合的订单数 / 总订单数 return {c: cnt for c, cnt in count.items() if cnt / n >= min_support} def apriori(transactions, min_support): """Apriori 主循环：从 1-项集开始逐层扩展。""" n = len(transactions) # 频繁 1-项集：统计每个单品出现次数 item_counts = Counter() for t in transactions: for item in t: item_counts[item] += 1 freq_map = {} # k -> 频繁项集字典(项集->支持度) freq_1 = {frozenset([item]): cnt/n for item, cnt in item_counts.items() if cnt / n >= min_support} if not freq_1: return freq_map freq_map[1] = freq_1 k = 2 prev_freq = set(freq_1.keys()) while prev_freq: candidates = generate_candidates(prev_freq, k) freq_k = filter_by_support(candidates, transactions, min_support, n) if not freq_k: break freq_map[k] = freq_k prev_freq = set(freq_k.keys()) k += 1 return freq_map

主函数的执行流程是这样的：第一轮统计所有单品出现次数，筛出频繁 1-项集；然后进入 while 循环，每轮调用 generate_candidates 生成下一轮候选集，再用 filter_by_support 统计支持度，直到某轮没有候选集达标为止。生成的 freq_map 是一个字典，键是项集大小 k，值是一个 dict，保存频繁项集及其支持度。

generate_candidates 里面用的是双重循环和并集操作。两个 k-1 项集如果前 k-2 个元素完全相同、最后一个元素不同，并集正好是 k 项；但这里为了代码简单直接取并集再判断长度，虽然会重复计算一些相同的组合，好在有 set 自动去重。如果要进一步优化，可以改成“前 k-2 个元素相等才连接”的方式，减少无意义的并集运算。filter_by_support 是最耗时的部分，可以优化的地方在于提前把候选集按大小排序，或在事务更长时用二分交叉验证，小规模数据没必要做。

参数 min_support 的取值没有固定答案，我在第 4 章会详细讲怎么按数据分布去定。这里只提醒一点：支持度阈值与订单总量直接相关，固定值 0.01 在一万条订单里意味着至少 100 个订单包含该组合，在十万条订单里就是 1000 个，业务含义完全不一样。所以不要从别的项目里抄一个阈值就用于新数据，一定要先看数据规模。

3.3 为什么用 frozenset 而不是 set 或 list

这个问题在实现时反复出现，单独拿出来说。关联规则挖掘里，项集天然是集合：没有顺序概念，也没有重复元素。list 有顺序，还要自己做去重，而且在做 issubset 判断时会退化成逐元素比较，效率不如集合的哈希运算。set 虽然语义正确，但它是可变对象，无法作为另一个集合的元素，也无法作为字典的键。

frozenset 完美解决了这两个问题：语义上是不可变集合，可以放心地放进 set 去重，也可以做 dict 的键用来存支持度计数。写这段 Apriori 实现时，所有项集一律用 frozenset，事务也是 frozenset，这样候选集去重、支持度字典、频繁项集的子集判断都变得极其自然。

还有一个细节：在规则提取阶段，要枚举一个频繁项集的非空真子集，用combinations(itemset, r)来生成，生成出来的是 tuple，必须用frozenset(tuple_val)转一下，才能继续和事务做 issubset 运算。很多人在这里容易忘记转换，导致类型不匹配的报错。记住一个原则：在 Apriori 的全流程里，项集只用 frozenset 一种类型，遇到 tuple 或 list 一律转换后再用。

4. 从频繁项集到关联规则：置信度过滤与三个必调参数

4.1 规则生成代码：枚举子集、计算置信度与提升度

频繁项集只是中间产物，业务真正要的是规则。规则的形式是 X → Y，X 是前件，Y 是后件，两者不相交，且 X ∪ Y 是某个频繁项集。生成规则的标准做法是：对每个频繁项集，枚举所有非空真子集作为前件，剩下的部分作为后件，再计算置信度和提升度做过滤。

from itertools import combinations def generate_rules(freq_map, transactions, min_confidence, min_lift=1.0): """从频繁项集生成关联规则。 freq_map: apriori() 返回的 {k: {frozenset: support}}。 返回规则列表，每一条是 (前件, 后件, 支持度, 置信度, 提升度)。 """ n = len(transactions) # 先建一个项集->支持度的全局映射，方便快速查 support_map = {} for freq_sets in freq_map.values(): support_map.update(freq_sets) rules = [] for freq_sets in freq_map.values(): for itemset, sup_xy in freq_sets.items(): # 只有长度 >= 2 的项集才能拆出有意义的规则 if len(itemset) < 2: continue for r in range(1, len(itemset)): for antecedent_tuple in combinations(itemset, r): antecedent = frozenset(antecedent_tuple) consequent = itemset - antecedent if not consequent: continue sup_x = support_map[antecedent] confidence = sup_xy / sup_x # 提升度 = P(XY) / (P(X) * P(Y)) sup_y = support_map[consequent] lift = sup_xy / (sup_x * sup_y) * n if confidence >= min_confidence and lift >= min_lift: rules.append((antecedent, consequent, sup_xy, confidence, lift)) return rules if __name__ == '__main__': freq_map = apriori(transactions, min_support=0.02) rules = generate_rules(freq_map, transactions, min_confidence=0.5, min_lift=1.2) for r in sorted(rules, key=lambda x: x[4], reverse=True)[:10]: print(f'{set(r[0])} -> {set(r[1])} conf={r[3]:.2f} lift={r[4]:.2f}')

规则生成的逻辑关键在枚举子集时用了 combinations 生成所有 r 元素子集，而 r 从 1 取到 len(itemset)-1，保证前件非空、后件也非空。支持度直接查前面构建的 support_map，不需要重新扫描事务。置信度用 sup_xy 除以 sup_x，这要求 sup_x 必须提前算好，否则频繁项集存了支持度也一样白搭。

这里要特别注意浮点精度问题。提升度的计算里乘了 n，是为了把概率值还原回计数做比值，减少浮点精度误差。如果用概率直接除，当 sup_x 和 sup_y 都很小时，小数点后好几位才出现差异，排序时容易因为浮点噪声产生不稳定的顺序。

4.2 支持度阈值与置信度阈值的设置顺序

很多人调参是一上来就设 min_support=0.5，把数据扫一遍发现什么都不剩，然后把阈值调低，再扫一遍又得到几千条规则，陷入死循环。我建议的顺序是：先看数据里的单品频次分布，再定支持度下限；先定支持度，再定置信度。

具体操作是跑一个统计脚本，把每个单品出现次数降序排列，看尾部到底有多长。如果 80% 的商品只出现在个位数订单里，那 min_support 就不该设成一个让他们全部通过的低值。结合实际项目经验，我一般先用 min_support=0.02 试跑一版，看频繁 1-项集还有多少个、2-项集有多少个；如果 2-项集数量超过 2000，就把阈值调高一倍；如果频繁 2-项集只有几十个，就调低一点。目标是让频繁 2-项集数量落在 200～500 区间，这是规则生成阶段的一个比较舒适的输入规模。

置信度阈值和业务场景强相关。比如做一个“搭配购”推荐位，用户看到规则后真正会下单的概率通常很低，置信度 0.2 可能都算高；但如果是做一个比对提示“买了相机的人也会买存储卡”，这就是强因果关系，置信度至少要到 0.6。我的经验是：先用一个偏低的置信度（0.3～0.5）把规则拉出来，人为浏览一遍 top 规则，再决定要不要收紧。因为置信度体现的是数据里的事实在，有些场景置信度天然高但没业务价值，需要人工参与判断。

最后才看提升度的过滤。提升度小于 1 的规则意味着“买了 A 反而不太会买 B”，这种规则在“互斥推荐”场景里其实有用，但一般默认过滤掉。所以在 generate_rules 里我把 min_lift 设成了可传参，默认 1.0，真实使用时按业务决定是否要收紧到 1.2 或 1.5。

4.3 商品粒度、重复购买、同购次数对结果的隐藏影响

同样的订单数据，粒度不同挖掘结果完全不同。如果把“红色 iPhone 手机壳”和“黑色 iPhone 手机壳”作为两个独立商品，支持度会被稀释，很难进入频繁项集；如果归一到“iPhone 手机壳”，支持度就能上来。这里没有绝对的对错，只有业务口径：你想推荐的是具体 SKU 还是品类？我做搭配推荐时一般先按品类做一轮挖掘，拿到规律后再把规则里的品类细化到 SKU，分两步走，直接跑 SKU 级 Apriori 的结果往往又稀疏又难解释。

重复购买的影响容易被忽略。同一个用户在同一笔订单里买了两件同样的商品，是否需要去重？如果不去重，项集表示本身就不符合集合概念。我在 load_transactions 里用的 set 已经天然去重了，但如果你的源数据是商品维度一行一条记录的，也没有做聚合去重，就会出现一个订单里同一个商品出现多次的情况。建议在加载数据时就统一 set 化处理。

还有一个指标容易和关联规则混淆：同购次数。支持度统计的是一个组合出现在多少个订单里，应该按订单维度去重后再数；如果按订单明细行数去统计，组合里商品全都被重复放大，支持度虚高，规则也会失真。每次入手新数据集，我都会先做一个校验：随机抽 3 个已知商品组合，人工核对它们在同一订单里的出现次数，和代码算出来的支持度对比，一致后再信结果。

5. Apriori 实现避坑指南：五条血泪经验

5.1 候选集内存溢出：商品数不大但组合数爆炸

有一回我用 Apriori 处理一批餐饮订单，每个订单平均 8 个菜品，总共 200 个不同的菜。看起来量不大，但 min_support 设成 0.001 之后，频繁 2-项集直接冲到上万，3-项集更是几何级膨胀，跑了十分钟还没出结果，内存一直在涨。原因是每个候选集都存成 frozenset，组合数一多内存开销特别大。

解决方法是先统计平均订单长度和商品维度，估算候选集规模。公式是 C(m, k)，m 是频繁项集个数。如果 C(200, 3) 约 131 万，配合低支持度阈值，3-项集必然爆炸。我当时把 min_support 从 0.001 调到 0.005，候选集数量立刻降到原来的几十分之一。另一个有效手段是在 generate_candidates 里加剪枝：如果一个候选集的任意 k-1 子集不在频繁项集集合里，直接丢弃，这比生成后再过滤节省大量内存。

5.2 支持度阈值拍脑袋定，结果空无一物

项目刚起步时最常碰到的现象是：设 min_support=0.1 跑完，频繁项集列表是空的，或者只有零散几个单品。原因很直白，业务数据里商品极度分散——每个订单包含的商品种类多但每家店销量都不高。0.1 意味着一个组合至少出现在 10% 的订单里，对长尾商品来说根本不可能。

我当时的选择是先统计各商品的订单覆盖率，发现覆盖率超过 5% 的商品只占全部商品的 2%。于是把 min_support 降到 0.01，再配合第 4 章的调试法看输出量，规则数量才进入可用区间。给新数据集调参时，永远先看一眼覆盖率的分布曲线，再决定阈值。直接从 0.1 往下盲调是最耗时的做法。

5.3 置信度很高但提升度小于 1：统计陷阱

某次结果里有一条规则“可乐 → 薯片”，置信度高达 0.62，看起来“买了可乐的顾客大概率也买薯片”。但我把提升度一算，只有 0.87。这里的问题在于：薯片本身是高频商品，全站 70% 的订单里都有薯片，所以买可乐的顾客里 62% 买薯片，还低于平均值。这个规则表面强、实际弱，推送出去不会有增量效果。

这正是只看置信度不看提升度的典型翻车。解决方案就是在规则生成阶段同时过滤 min_lift，把小于 1 的规则全部丢弃或单独标记。我在 generate_rules 里默认加了这个参数，就是提醒自己：任何规则强制算一遍提升度再决定是否进入备选池。

5.4 商品编码不统一：两个名字其实是同一个商品

处理真实数据时发现 A 系统导出的商品名是“iPhone 15 Pro 256G 原色钛金属”，B 系统导出的是“iPhone15Pro 256GB 原色钛金”。两个编码看起来不同，但都是同一个商品。Apriori 的结果里出现了一条匪夷所思的规则：“买 iPhone 15 Pro 的人不买 iPhone15Pro”，其实只是数据问题导致的假分裂。

解决手段是在数据准备阶段做一次商品名归并，涉及去掉空格、统一大小写、别名映射。更稳的方式是直接用商品 ID 而不是商品名做关联规则，展现层再做名称映射。如果只能用名称，就要先跑一轮品名清单，肉眼扫一遍有没有疑似重复项。这个步骤虽然不“技术”，但能避免后面所有规则都建立在错误的数据地基上。

5.5 一条订单十几行相同商品，支持度虚高

还有一次的数据量看起来很大，几百万行明细，Apriori 却卡到无法执行。排查后发现问题出在订单明细是“商品行”结构，一条订单里有十个商品就记十行，某个组合在同一个订单里出现了多次，代码却按照明细行数去计数，支持度被放大了好几倍。

修正方式是回到 load_transactions 阶段，以订单号为维度聚合，用 set 保存该订单的所有商品，再参与计数。统计一下去重后的订单总数和明细行数的比值，如果差距大，就说明原始数据重复度很高，计数逻辑必须先按订单聚合。这也是我每次拿到新数据第一个统计字段设置为订单数量的原因。

6. 让 Apriori 的结果真正进业务：规则打分、排序与验证习惯

算法跑通只是第一步，能交付给业务看的规则才算是完成。我最后收尾的做法是给规则算一个综合得分，然后做可视化验证，再落成定时任务。综合得分用的是置信度乘以提升度，这样既照顾到命中率，又照顾到增量价值。

def score_rules(rules, top_n=50): """给规则打分并返回 Top-N。分 = 置信度 * 提升度，再加一个小惩罚项。""" scored = [] for antecedent, consequent, sup, conf, lift in rules: # 前件太长曝光率低，适当降权 penalty = 1.0 if len(antecedent) <= 2 else 0.8 score = conf * lift * penalty scored.append((antecedent, consequent, sup, conf, lift, score)) scored.sort(key=lambda x: x[5], reverse=True) return scored[:top_n]

打分函数里我加了一个前件长度的惩罚因子：前件超过 2 个商品的规则，在推荐位展示时用户理解成本高，实际点击率明显下滑，所以要降权。Top-N 名单出来之后，我习惯用 matplotlib 画一张支持度为横轴、置信度为纵轴、气泡大小映射提升度的散点图。一眼就能看出哪些规则是“高频低质”、哪些是“低频高质”，然后人工决定推哪批。

验证规则是否真的有效，一个可复现的方法是留一法：把数据按时间切成训练集和验证集，用前 30 天的数据挖规则，看规则在接下来 7 天订单里的命中率和提升度是否还站得住。如果验证集上提升度掉到 1 以下，说明这条规则只是短期巧合，不能上线。我现在的习惯是任何规则在正式推送前做一次这样的时间切片验证，宁愿少发几条也不推错。

定时任务层面，Apriori 的输入是订单数据，一般一天凌晨跑一次就够了。把 load_transactions、apriori、generate_rules、score_rules 串成一个脚本，输出 CSV 给运营系统读取，整个过程在万级订单上跑完不超过几分钟。

最后说一个我自己的教训：第一次上线规则推荐时，我直接推了 top 50 条规则，结果点击率还不如运营手工搭的组合。后来复盘发现，top 规则里大部分是互补品类里的爆款互带，提升度虽然大于 1，但增量价值有限。从那以后，我坚持在打分时把单品自身的热度也纳入考量，让规则倾向推荐“不那么热门但和用户当前选择关联明显”的商品，效果才真正起来。调参、验证、回归，这套习惯比特地去找新算法更有用。希望帮到你。

本文还有配套的精品资源，点击获取