记得 2022 年底，ChatGPT 刚出来的时候，很多人都只是把它当做一个玩具。因为当时的版本是 GPT-3.5，还并不是很智能，我们做个对比。

可以看到 GPT-3.5 不会对用户的问题提出质疑，有时也会说一堆正确的废话，总之得不到想要的答案。

当时我已经隐隐感觉到，搞技术的人天要塌了，但我并没有布局 AI，也没有持仓英伟达，因为没那个高瞻远瞩的眼光。毕竟谁能想到，短短几年时间，AI 能发展得这么迅猛。

之后 Claude 诞生了，我看推特上都在说自己已经转向 Claude 了，于是我也抱着兴趣试了试。试了之后发现，这玩意写代码简直无敌，之后我便退订 GPT，订阅 Claude 了。

然后一直用到现在，直到号被封，现在想想心还在滴血。当然除了 Claude，我还用 Gemini，这是我薅了谷歌的羊毛，送了我 15 个月的 Gemini Pro。

所以之前我都是 Claude 和 Gemini 搭配使用的，这两个 AI 都挺不错，我实际用下来体验感很好。但现在 Claude 被封了，正好 OpenAI 说他们发布了 GPT-5.4，并给出了测试报告。

所以我决定回归 GPT。

不得不说这些 AI 厂商之间，大有一幅你方唱罢我登场的样子，你发布了新版本的模型，过段时间我也要发布一个。

最后向大家介绍这几个 AI 的充值办法。

Gemini 的话很简单，因为谷歌对银行卡的限制不严格，你用国内招商的全币种 Visa 就可以。但 GPT 和 Claude 不行，你在充值的时候如果用国内的银行卡，基本都会被拒绝。

Claude 的话，你需要有一台 iPhone，然后在 App Store 里面搜索 Claude，将 APP 下载下来。注：下载之前需要将地区改成美国，因为大陆地区搜不到。

下载完之后将地区改回去，这样就可以绑定支付宝了，然后直接打开 Claude App 订阅即可。假设你订阅的 Pro，一个月 20 美元，会直接按照汇率计算出人民币，从你的支付宝里面扣除。

最后是 GPT，我们同样要使用 iOS 订阅，但它更复杂一些。因为当你将地区改成中国大陆之后，GPT 会感知到，它不让你支付，或者说支付失败，所以你的 App Store 从始至终都必须是美国地区。

但美国地区无法绑定支付宝，经过测试，国内 Visa 也会被拒，那怎么办呢？还是点击支付宝，搜索 Pockyt Shop。

点击 App Store，然后充值对应的美元即可。由于人民币涨了，所以充值 20 美元，大概花费 138 块多。付款成功之后，会给你一个 16 位的充值码，复制下来并打开 App Store，然后点击头像。

直接充值兑换即可，这样账户就有钱了，然后订阅即可。如果你的 App Store 里面有足够的钱，那么会立刻订阅成功，只有当你的账户没钱时，才会让你绑卡。

好，以上就是我使用 AI 的历程。还是多说一句，一定要拥抱 AI，技术越来越不值钱了。但问题是怎么用 AI 变现，相信大部分程序员都没有啥好的思路，这大概就是我们这些搞技术的局限性吧。

而那些拥有产品思维的人，却总能精准抓住用户需求，实现变现。比如 "小猫补光灯" 和 "死了么" 这两个 App，从技术含量来看几乎没有，但就是能火起来。

所以给初入职场的小伙伴一个建议，不用太过努力、太痴迷技术，除非你是 Top 0 级别的，否则很难有好下场。时代、机遇、偶然的好运，以及学会处理人际关系，远比搞技术更重要。当然最重要的是，要有一副好身体，不要卷到最后，把钱都给医院了。该休息就休息，该摸鱼就摸鱼。

跳转微信打开

今天用 Claude 的时候发现号被禁了，虽然可以正常登录，但不让提问。

我懵逼了，啥情况这是。

我知道 Claude 封号严重，但问题是我都用几年了，为啥今天突然被封了。

在此之前，我经常看到有人吐槽自己 Claude 账号被封，哪怕 IP 固定也被封。而我呢，不仅 IP 经常变，哪个国家的延迟低用哪个，而且还分享给我朋友，我俩一起用，从来没出过事。

我思考过原因，觉得可能有三种原因。

• 1）我用的 IOS 订阅。

• 2）账号注册得很早，对于老用户，不进行风控，或者风控不严格。

• 3）单纯运气好，铁拳没有制裁到我（最不想看到）。

直到我收到了 Anthropic 发来的邮件。

这时候我想起来了，前两天我参与了 Claude 官方的一个活动。就是如果你在 github 上是知名项目的核心开发或维护者，或者有 star 数超过 5000 的项目等，那么可以免费申请 Claude Max 20。

于是前天我闲的没事，就申请了一下，结果今天被封了。思来想去，觉得应该就是这个原因，不然也太巧了，用了几年都没事，结果申请之后就被封了。

真的哔了狗了，会不会是 Anthropic 通过 github 推断我来自 China，然后就把我的号给封了。

最后不管怎样，Anthropic，我想对你说。

跳转微信打开

在信贷风控领域，短信特征（即从借款人授权的短信内容中提取的结构化信息）正扮演着越来越重要的角色。它的核心价值在于，为金融机构提供了一个独特且有效的窗口，以评估那些传统征信记录覆盖不足或缺失的客群的信用风险。这对于拓展普惠金融服务、提升风控模型的精准度和覆盖面具有重要意义。

短信特征在信贷风控中的主要用途可以归结为以下几个方面：

• 补充传统征信的不足： 对于缺乏央行征信记录或信贷历史较短的 "信用白户"，短信数据成为了评估其还款意愿和还款能力的重要替代数据源，通过分析短信中的消费、缴费、收入等信息，可以初步勾勒出用户的财务状况。

• 多维度交叉验证，防范欺诈风险： 短信特征可以与用户在申请贷款时提交的其它信息进行交叉验证。例如可以通过分析银行、三方支付等发送的交易短信，核实用户的收入流水、消费水平和负债情况，有效识别信息造假和潜在的欺诈行为。

• 构建更全面的用户画像： 短信内容涵盖了用户生活的方方面面，通过对这些非结构化数据进行深度挖掘和分析，可以构建出比传统数据更为立体和丰富的用户画像，这有助于更精准地评估用户的信用等级。

风控模型通常会从海量的短信数据中提取出多种维度的特征，这些特征共同构成了对借款人信用的综合评估。那么从短信中可以挖掘出哪些关键特征呢？

而对于出海现金贷，我们通常关注的是最后一个，那么具体都要做哪些工作呢？

1）关键词匹配与规则引擎

首先风控系统会内置一个庞大的、持续更新的关键词库和规则库，这些库包含了市面上几乎所有已知现金贷平台的信息。

然后通过发件人的号码或名称、以及匹配关键词，来识别是否是现金贷平台发送的短信。

2）自然语言处理（NLP）

对于更复杂的短信，简单的关键词匹配可能不够，因为有可能是平台广告，这时就需要引入 NLP 技术来判断短信的真实意图。

3）文本挖掘

从文本中提取关键的结构化信息，比如借款平台名称、申请时间、申请金额、授信额度、放款金额、还款日、是否命中指定的关键词等。

当然啦，如果你知道其它现金贷平台的短信格式，能够区分出广告，那么 NLP 这一步也可以省略。

4）特征工程与指标计算

当短信被识别和解析后，系统会围绕多头借贷和逾期这两个核心风险点，构建一系列量化特征指标。

• 申请平台数量： 在特定时间窗口内（如过去 7 天、15 天、30 天），用户向多少个不同的贷款平台发起了申请？如果平台过多，说明可能存在资金紧张、有多头借贷风险。

• 申请频率： 用户在短期内申请贷款的次数。例如一天内向超过 3 个平台发送注册验证码请求，就是一个强烈的风险信号。

• 命中高风险平台数量： 用户是否在已知的高利贷、套路贷或风控口碑差的平台上进行过申请？

• 信贷审批通过率： 在所有申请的平台中，有多少比例的申请被批准了？如果申请了很多家但都失败了，说明该用户资质可能存在严重问题。

• 贷平台数量： 根据放款和还款短信，判断用户当前同时在多少个平台上有尚未结清的贷款。

• 逾期次数、天数：判断短信是否命中逾期、催收等关键词，获取逾期次数和天数。

基于以上特征便可以构建准入策略了，比如逾期次数大于 3，直接拒绝；使用的现金贷平台数量大于 10，直接拒绝。

所以短信特征工程的本质是通过用户的数字行为轨迹来评估其信用风险和还款能力，这套系统特别聪明的地方在于：

• 全景视角：不只看一家的贷款记录，而是看整个市场的信贷行为。

• 动态追踪：通过时序特征捕捉用户信用状况的变化趋势。

• 细粒度分析：从 APP 级别到具体的金额、期限、逾期天数等。

• 行为预测：基于历史模式预测未来的还款表现。

核心就是：你的短信暴露了你的真实财务状况。出现逾期，代表还款能力有问题；出现多平台借贷短信，代表资金紧张；出现催收短信，代表信用状况恶化。

所以短信特征本质上就是通过短信文本分析来做信用评估，这比传统的征信报告更加实时和全面，所以它在风控领域中非常重要。

关于短信特征，我们就简单聊了一下，当然接下来才是本文真正的重点。我们说了，要通过解析短信文本来构建一系列特征指标，那么这个解析过程该怎么做呢？

毫无疑问，解析过程的核心是关键词匹配，所以正则就是一个非常自然的选择。但我们不能光依赖正则，因为在匹配具体的关键词时，正则的速度不够快，我们还需要一个模块叫 ahocorasick。

有一个算法叫 Aho-Corasick，也被称为 AC 自动机，该算法是一种高效的字符串匹配算法，它能一次性在一个文本中查找多个模式串（关键词）。该算法的巧妙之处在于，无论你有多少个关键词，都只需要对主文本进行一次遍历即可完成查找，因此效率极高。你可以把它想象成升级版的 KMP 算法，KMP 是为了解决一个模式串的匹配问题，而 Aho-Corasick 则是为了解决多个模式串的匹配问题。

AC 自动机的具体原理这里就不赘述了，只需要知道它很高效，时间复杂度为 O(N+M+K)，其中 N 是主文本长度，M 是所有模式串的总长度（用于构建 Trie 树），K 是匹配到的模式串数量。因此可以看出，AC 自动机和模式串的数量无关，即不管 K 是多少，都只需要遍历一次主文本。

Aho-Corasick（AC 自动机）因其高效的多模式匹配特性，广泛应用于以下场景。

• 敏感词过滤：在论坛、聊天室等场景中，需要从用户输入中快速过滤掉大量的敏感词、广告词，AC 自动机是实现这个功能的理想选择。

• 网络入侵检测系统（NIDS）：通过维护一个包含大量已知攻击模式（如病毒签名、恶意代码片段）的字典，AC 自动机可以实时地在网络流量中检测是否存在这些攻击模式。

• 生物信息学：在 DNA 或蛋白质序列中快速查找多个特定的基因序列模式。

• 拼写检查和自动纠错：将正确的单词作为模式串，快速在文本中找到不存在于字典中的词。

• 多头借贷检测：在用户授权的短信中，将各个借贷平台的名称和对应关键词作为模式串集合，可以快速地一次性扫描所有短信，识别出多头借贷行为。

而 ahocorasick 模块正是 Aho-Corasick 算法的具体实现，执行 pip install pyahocorasick 安装之后，来看一下它的使用方法。

import ahocorasick
A = ahocorasick.Automaton()
# 添加关键词
A.add_word("what", None)
A.add_word("how", None)
A.add_word("when", None)
A.add_word("then", None)
# 查找所有的关键词
print(list(A.keys()))  # ['then', 'how', 'when', 'what']
# 查找以 "w" 开头的关键词
print(list(A.keys("w")))  # ['when', 'what']
# 查找长度为 4 的关键词，
print(list(A.keys("****", "*")))  # ['then', 'when', 'what']
# 第二个参数为通配符，一旦指定了，那么第一个参数就不再是前缀了
# 此时 "*e" 表示精确匹配长度为 2、以 "e" 结尾的关键词
print(list(A.keys("*e", "*")))  # []
print(list(A.keys("w", "*")))  # []
print(list(A.keys("**e", "*")))  # []
print(list(A.keys("**en", "*")))  # ['then', 'when']
# 判断某个关键词是否存在（只能精确匹配）
print(A.exists("whe"))  # False
print(A.exists("when"))  # True
# 判断是否存在具有指定前缀的关键词
print(A.match("whe"))  # True
print(A.match("when"))  # True
# 获取某个关键词的 value（只能精确匹配）
# 关键词不存在会报 KeyError，但可以指定默认值
print(A.get("when"))  # None
# 这个不好解释，我们直接用代码说明
# "when" 长度为 4，能命中已有关键词
print(A.longest_prefix("when"))  # 4
# "while" 长度为 5，但只有前两个字符能和已有关键词具有相同的前缀
print(A.longest_prefix("while"))  # 2
print(A.longest_prefix("w"))  # 1
# 没有任何一个关键词的前缀是 "ow"
print(A.longest_prefix("ow"))  # 0
# 如果不想要某个关键词了，那么也可以移除
A.pop("when")
print(list(A.keys()))  # ['then', 'how', 'what']
# pop 方法在 key 不存在时会跑抛出 KeyError
# 如果希望不报错，那么可以使用 remove_word 方法，成功移除返回 True，关键词不存在返回 False
A.remove_word("how")
print(list(A.keys()))  # ['then', 'what']
print(list(A.keys()))  # ['then', 'what']
# 清空所有关键词
A.clear()
print(list(A.keys()))  # []

以上这些方法只是开胃菜，因为我们用字典也可以实现，下面来看它最重要的一个用法。

import ahocorasick
A = ahocorasick.Automaton()
# 添加关键词
key_words = ["what", "how", "when"]
for index, key_word in enumerate(key_words):
# value 可以是任何对象，这里我们用 (index, key_word) 元组
    A.add_word(key_word, (index, key_word))
# 构建自动机，只有在构建完自动机之后，才可以搜索
A.make_automaton()
# 原始文本
original_text = "what are you doing? how do you do? when i was young, i'd listen to the radio."
# 调用 iter 方法进行搜索，该方法会返回一个迭代器，迭代出的每个元素是一个元组 (end_index, value)
# 其中 end_index 表示匹配到的关键词在文本中的结束位置（包含），value 表示添加关键词时指定的 value
# 我们看到没有返回关键词，所以在 add_word 时要将关键词体现在 value 中，当前的 value 是 (index, key_word)
for end_index, (index, key_word) in A.iter(original_text):
    print(f"original_text[{end_index + 1 - len(key_word)}: {end_index + 1}] 对应关键词 {key_word}，"
f"即 key_words[{index}]")"""
original_text[0: 4] 对应关键词 what，即 key_words[0]
original_text[20: 23] 对应关键词 how，即 key_words[1]
original_text[35: 39] 对应关键词 when，即 key_words[2]
"""print(original_text[0: 4])  # what
print(original_text[20: 23])  # how
print(original_text[35: 39])  # when

通过这种方式，只需一次遍历，就可以找到所有匹配的关键词。当然啦，大部分时候我们不关心匹配的单词在原文中的位置，只是想统计数量。

import ahocorasick
A = ahocorasick.Automaton()
key_words = ["what", "how", "when"]
for index, key_word in enumerate(key_words):
    A.add_word(key_word, key_word)
A.make_automaton()
original_text = "what how when when how how how what"
result = {}
for _, key_word in A.iter(original_text):
if key_word notin result:
        result[key_word] = 0
    result[key_word] += 1
print(result)  # {'what': 2, 'how': 4, 'when': 2}

需要注意的是，这些关键词在原文中都是分开的，即使它们连在一起也没问题。

original_text = "whathowwhenwhenhowhowhowwhat"
result = {}
for _, key_word in A.iter(original_text):
if key_word notin result:
        result[key_word] = 0
    result[key_word] += 1
print(result)  # {'what': 2, 'how': 4, 'when': 2}

结果是一样的，因为 AC 自动机在遍历时不在乎关键词的右边是否是空格。

另外 AC 自动机在匹配时，如果原始字符串的一个范围能匹配多个单词，那么这些单词都会返回。

import ahocorasick
A = ahocorasick.Automaton()
key_words = ["he", "she", "his", "hers"]
for index, key_word in enumerate(key_words):
    A.add_word(key_word, key_word)
A.make_automaton()
original_text = "ushers"
for end_index, key_word in A.iter(original_text):
    print(f"original_text[{end_index + 1 - len(key_word)}: {end_index + 1}] 对应关键词 {key_word}")"""
original_text[1: 4] 对应关键词 she
original_text[2: 4] 对应关键词 he
original_text[2: 6] 对应关键词 hers
"""

以上就是 ahocorasick 的用法，当然它还有一些其它方法，不过不常用。我们使用这个模块，主要就是做关键词匹配。

阅读原文

跳转微信打开

最近收到不少小伙伴的私信，在这里统一回复：谢谢大家关心，我还活着，只是不更新了而已。然后也有小伙伴从几个月前就一直问我啥时候更新，我的回答是没啥好更新的了，建议大家一定要拥抱 AI，生产力绝对会成倍提升。

但话都说到这儿了，不更新一篇也不合适。由于目前正在从事风控领域，就更新一篇风控相关的文章吧。

在信贷风控领域，特征分箱（Feature Binning）是一项至关重要且应用广泛的特征工程技术，它的作用是将连续型特征（如年龄、收入）或多取值的离散型特征（如职业）进行分组、装箱，将其转化为一系列离散的区间或类别。这一看似简单的操作，在构建稳定、可解释且高效的信用评分卡等风控模型中，扮演着定海神针般的关键角色。

而之所以要特征分箱，是因为在原始的连续型特征上直接建模，往往会遇到诸多挑战。而特征分箱通过将数据离散化，带来了多方面的显著优势。

• 提升模型的稳定性和鲁棒性：分箱操作能够有效降低特征中 "噪声" 的干扰。例如借款人年龄的微小变动（从 30 岁变为 31 岁）可能并不会对其信用风险产生实质性影响，分箱后，这些细微的波动被平滑处理，能有效防止模型因过度拟合个别数据点而变得不稳定，从而增强模型的泛化能力，使其在面对新数据时表现更稳健。

• 增强模型的可解释性：将连续特征转化为有限的几个箱，极大地增强了业务人员对模型决策逻辑的理解。例如，相比于 "年龄每增加一岁，违约概率下降 0.5%" 这种复杂的线性关系，"年龄在 30 ~ 40岁之间的客群，其信用风险较低" 这样的结论显然更直观，更易于向决策层和业务部门解释和沟通。

• 有效处理非线性关系：现实世界中，许多特征与信用风险之间并非是简单的线性关系。例如，年龄与违约率可能呈现 U 型关系，即年轻人和老年人的风险相对较高，中年人风险较低。分箱操作可以将这种非线性关系转化为分段的线性关系，使得逻辑回归等线性模型也能有效捕捉到这种复杂的模式。

• 便捷地处理缺失值和异常值：在进行分箱时，可以将缺失值或异常值作为一个独立的 "箱" 来处理。这不仅避免了复杂的缺失值填充或异常值剔除操作，还能将 "缺失" 或 "异常" 本身作为一种信息纳入模型考量，有时这些特殊值本身就蕴含着特定的风险信息。

• 为后续的 WOE 转换和评分卡创建奠定基础：在构建信用评分卡时，特征分箱是计算证据权重（Weight of Evidence，WOE）和信息价值（Information Value，IV）的前提。WOE 可以衡量每个分箱内好坏客户的比例差异，从而揭示该分箱对风险的预测能力。

特征分箱的方法主要有以下几种：

• 等宽分箱（Equal Width Binning）

• 等频分箱（Equal Frequency Binning）

• 卡方分箱（Chi-Merge Binning）

• 决策树分箱（Decision Tree Binning）

等宽分箱

核心思想：将特征的取值范围（最大值 ~ 最小值）等分成 N 个区间。

这种做法实现简单、快速，但缺点也很明显。如果特征值分布不均，容易产生某些箱内样本量过多，而另一些箱内样本量过少的情况，导致分箱结果无意义。

因此等宽分箱一般用于数据分布比较均匀的特征，或作为快速探索性分析的初步分箱方法。

等频分箱

核心思想：将特征按从小到大的顺序排列，然后切分成 N 个部分，使得每个部分（箱）内的样本数量大致相等。

这种做法保证了每个箱内都有足够的样本量，避免了等宽分箱的缺点。但它自身也有缺点，因为可能会将数值上非常接近的样本点强行切分到不同的箱中，对于某些业务场景，这种纯粹基于频率的切分可能破坏了原有的业务逻辑。

卡方分箱

等款分箱和等频分箱针对的是无监督样本，而卡方分箱针对的是有监督样本。其核心思想是利用卡方检验（Chi-Square Test）来衡量相邻两个区间的分布相似性，从最小的箱开始，不断合并卡方值最小的相邻箱，直到满足停止条件（如分箱数、卡方阈值）。

这种做法是一种基于目标变量（如是否违约）进行分箱的监督方法，能保证分箱后的每个箱都有显著不同的风险水平。至于缺点是计算相对复杂，对某些值域的样本量敏感。

卡方分箱在构建信用评分卡时非常常用，因为它能确保分箱结果与风险有很强的关联性。

决策树分箱

针对有监督样本，核心思想是利用单特征构建一个简单的决策树模型来拟合目标变量，树的每个叶子节点就代表一个分箱。

这种做法能自动找到最优的分割点，并且可以很好地处理非线性关系，分箱结果与目标变量强相关。但缺点是容易过拟合，需要通过剪枝或限制树的深度来控制，因此对于强线性关系的特征可能不是最优选择。

决策树分箱主要用于需要深度挖掘特征与风险之间非线性关系的场景。

下面来单独说一下卡方分箱（Chi-Merge Binning）的原理，因为它不像等宽和等频那么简单。

卡方分箱的哲学可以用一句老话来概括："物以类聚，人以群分"，它的核心目标是将特征值相近且目标值（如好坏客户）分布也相似的区间进行合并。最终保留下来的每个箱子，其内部的客户风险水平应该尽可能一致，而不同箱子之间的风险水平则要有显著的差异。

它是个自底向上的过程，和之后要介绍的决策树正好相反，先让每个特征值都自成一派（一个箱），然后通过一个标准去衡量哪些"派别"最相似，并将它们合并，不断重复这个过程，直到"派别"数量减少到我们满意的程度。而衡量派别相似的标准，就是统计学中著名的卡方检验（Chi-Square Test）。

所以要理解卡方分箱，就必须先理解它的数学引擎 - 卡方独立性检验。这个检验的目的是判断两个分类变量是否相互独立，在当前的场景中，这两个变量是：

• 分箱变量：即样本属于哪个箱子，例如箱子 A 还是箱子 B。

• 目标变量：即客户是好客户还是坏客户。

卡方检验会提出一个零假设（H₀）：分箱变量与目标变量相互独立。换句话说，零假设认为 "一个客户在箱子 A 还是箱子 B" 与 "他是一个好客户还是坏客户" 这两件事没有关系。如果这个假设成立，那么箱子 A 和箱子 B 中好坏客户的比例应该是没有显著差异的。

卡方检验会计算出一个卡方统计量（χ2 值），这个值衡量了实际观测值与期望值之间的差距。

• O（Observed）：观测频数，即我们实际统计到的、落在每个箱子里的样本数量。

• E（Expected）：期望频数，即如果零假设成立，我们理论上期望的样本数量。

如果 χ2 值很小，说明观测值（O）与期望值（E）非常接近，这意味着数据非常符合 "两个变量相互独立" 的零假设，因此我们没有理由拒绝零假设。在分箱场景下，这代表着这两个相邻的箱子，其好坏客户的分布非常相似，它们是合并的首要候选者。

如果 χ2 值很大：说明观测值（O）与期望值（E）差距巨大，这强烈地表明 "两个变量相互独立" 的假设是错误的，因此我们可以拒绝零假设。在分箱场景下，这代表着这两个相邻的箱子，其好坏客户的分布有显著差异，它们应该被分开，不能合并。

下面通过一个例子，来实际感受一下运算过程。

假设有以下数据，并且已经初始化，每个年龄段是一个独立的箱。我们想看看相邻的 20 ~ 30 岁和 31 ~ 40 岁这两个箱是否应该合并。

以上是我们的观测值，这是通过实际的统计得到的，是真实数据。而接下来要计算期望值，这是通过数学理论得到的。

第一步：计算期望值（Expected）

如果年龄段和是否坏客户无关（即零假设成立），那么 $20 \sim 30$ 岁年龄段的坏客户比例应该和总体的坏客户比例一样。

• 总坏客户比例 = 30 / 260 ≈ 11.54%

• 总好客户比例 = 230 / 260 ≈ 88.46%

现在我们可以计算每个格子的期望值 E = 行总计 * 列总计 / 总计。

• E(20 ~ 30, 好客户) = 90 * 230 / 260 ≈ 79.6

• E(20 ~ 30, 坏客户) = 90 * 30 / 260 ≈ 10.4

• E(31 ~ 40, 好客户) = 170 * 230 / 260 ≈ 150.4

• E(31 ~ 40, 坏客户) = 170 * 30 / 260 ≈ 19.6

第二步：计算卡方值

现在，我们将观测值和期望值代入公式。

此时我们便算出了 20 ~ 30 和 30 ~ 40 的卡方值 χ2，这个值为 0.026。

第三步：决策

我们会对所有相邻的箱子重复上述计算，假设区间再多一些，我们可能还会计算 31 ~ 40 和 41 ~ 50 之间的 χ2 值，比如计算出的结果为 2.5。

因为 0.026 < 2.5，所以 20 ~ 30 和 31 ~ 40 这对箱子的相似度更高，在这一轮迭代中，算法会优先选择合并 20 ~ 30 和 31 ~ 40，形成一个新的箱 20 ~ 40。

然后算法进入下一轮迭代，新的箱 20 ~ 40 会和它的邻居（如 41 ~ 50）再次计算卡方值，并寻找全局最小的卡方值进行合并。这个过程会一直持续下去，直到满足以下停止条件。

• 达到目标箱数（Max Bins）：这是最常用的方法，预先设定一个最终的分箱数量（例如 10 箱），当合并到只剩下 10 个箱子时，算法停止。

• 卡方阈值（Chi-Square Threshold）：设定一个卡方值的阈值，如果计算出的所有相邻箱的最小卡方值都大于这个阈值，说明即使是差异最小的两个箱，差异也已经很显著了，不应该再合并，算法停止。

• 最小箱体样本量（Minimum Bin Size）：要求每个箱子必须包含最少 N 个样本。如果合并后会导致某个箱子过大，而另一个箱子样本过少，则可以调整策略。或者在初始化时就预先合并一些样本极少的箱。

综上所述，卡方分箱的原理就是巧妙地利用卡方独立性检验，通过一个迭代合并的过程，不断地将目标变量分布最相似的相邻区间进行合并，从而找出最优的分箱切分点，确保最终的分箱结果在统计上具有区分度。

决策树分箱的核心思想是：如果一个决策树模型能用某个特征很好地预测客户的好坏，那么这棵树为了做出判断而找到的分割点，不就是天然的、最佳的分箱边界吗？因此它把分箱问题转成了一个简单的模型训练问题。

我们针对单个特征建立一棵决策树来预测目标，然后把这棵树的决策逻辑（即分割规则）直接翻译过来，作为分箱规则。因此决策树分箱的过程可以分解为以下几个步骤：

1）选择一个你想要分箱的连续型特征（例如 age）作为自变量 X，选择你的目标变量（例如 is_bad）作为因变量 y。

2）使用 X 和 y 来训练一个决策树分类器（DecisionTreeClassifier），但我们不能让这棵树无限生长，否则它会为了拟合每一个数据点而制造出无数个细碎的箱子，导致严重的过拟合。所以必须对它进行预剪枝，限制其复杂度，常用的剪枝方法如下。

• 限制最大叶子节点数（max_leaf_nodes），这是最直观的方法，如果想分成5个箱，就设定 max_leaf_nodes=5。

• 限制树的最大深度（max_depth），例如深度为 3 的树最多能产生 2^3=8 个箱。

• 限制叶子节点的最小样本量（min_samples_leaf），确保每个箱子，或者说每个叶子节点都包含足够多的样本，避免产生不稳定的、由少数样本构成的箱。

3）当决策树训练完成后，其内部已经包含了所有用于决策的分割点（也称为阈值）。我们可以从训练好的树模型中，把所有内部节点（非叶子节点）的分割阈值（threshold）提取出来。

4）将提取出的所有分割点进行去重和排序，在排序后的分割点列表的开头加上负无穷（-inf），在结尾加上正无穷（+inf），这就构成了一套完整的分箱边界。

5）使用这些边界，通过类似 pandas.cut 的功能，将原始的连续特征映射到其对应的分箱区间中。

假设我们用"年龄"特征训练了一棵决策树（max_leaf_nodes = 4），它最终的决策逻辑可能是这样的。

• 训练决策树：根节点以 age <= 55.5 为条件分裂，左子树（age <= 55.5）继续以 age <= 28.5 分裂，右子树（age > 55.5）不再分裂，成为一个叶子节点，age <= 28.5 的分支也不再分裂，最终形成了 4 个叶子节点（即 4 个箱）。

• 提取分割点：树中用到的分割点是 55.5 和 28.5。

• 形成边界：排序后为 [28.5, 55.5]，加上无穷边界后，完整的边界列表是 [-inf, 28.5, 55.5, +inf]。

• 最终分箱结果：箱 1 为 (-inf, 28.5]，箱 2 为 (28.5, 55.5]，箱 3 为 (55.5, +inf]。注意：这里因为树的结构，最终只产生了 3 个箱，即使我们设定了max_leaf_nodes=4。

那么决策树分箱有哪些优缺点呢？

优点

• 自动寻找最佳分割点：无需人工干预，算法能基于信息增益或基尼不纯度自动找到最优的分割边界，最大化箱内的纯度。

• 能捕捉非线性关系：这是它相较于卡方分箱等方法的一个巨大优势，如果特征与目标之间存在 U 型、倒 U 型等复杂关系，决策树可以通过多次分割来有效捕捉这种模式。

• 处理速度快：决策树的训练速度非常快，尤其是在特征维度很低时（我们每次只用一个特征）。

• 鲁棒性强：对于异常值不敏感，因为异常值只会被分到某个叶子节点，不会像等宽分箱那样严重影响整体的边界划分。

缺点

• 容易过拟合：如果不对树的复杂度进行严格限制（即剪枝），它会生成过多且不稳定的分箱，导致模型在测试集上表现很差。控制复杂度是使用此方法的关键。

• 结果可能不稳定：训练数据的微小变动可能会导致生成一棵完全不同的树，从而得到一套不同的分箱规则。

• 不保证单调性：决策树只关心如何最大化信息增益，它产出的分箱结果对应的风险率（或WOE值）不保证是单调的。这在需要强业务可解释性的评分卡场景中可能是一个问题，可能需要后续手动调整。

然后是这几种分箱的实现方式，我们可以借助 toad 库来实现，这是一个广受好评的 Python 库，尤其在评分卡建模领域，它提供了包括卡方分箱在内的一整套解决方案。比如除了卡方分箱，还集成了计算 WOE、IV、特征筛选、评分卡转换等一系列风控建模常用功能。

在信贷风控中，特征分箱的最终目的往往是为了计算 WOE 和 IV，进而构建信用评分卡。那什么是 WOE 和 IV 呢？

证据权重（WOE）

WOE 是对一个分箱内好客户（非逾期）与坏客户（逾期）比例的衡量，其计算公式为如下。

所以每个分箱的好客户占整体好客户的比例，除以坏客户占整体坏客户的比例，再取对数，便是对应分箱的 WOE。

举个例子，我们有 10000 个客户，8000 个好客户，2000 个坏客户。某个分箱里面好客户是 800 人，坏客户是 400 人，那么：

• Good_i / Good_total = 800 / 8000 = 10%

• Bad_i / Bad_total = 400 / 2000 = 20%

所以 WOE_i = ln(10% / 20%) = ln(0.5) = -0.693。

而基于 WOE 值，我们可以做出如下结论。

• 如果 WOE > 0：该分箱中好客户占比高于坏客户占比，属于低风险区间。

• 如果 WOE < 0：该分箱中坏客户占比高于好客户占比，属于高风险区间。

• 如果 WOE = 0：该分箱中好坏客户占比相等，风险中性。

在上面的例子中，WOE = -0.693 < 0，说明这个分箱是高风险的，因为坏客户的相对集中度（20%）高于好客户的相对集中度（10%）。

所以通过 WOE，可以标准化不同分箱的比较基准，消除样本不平衡的影响，以及提供直观的风险度量。

信息价值（IV）

IV 是用来衡量一个特征对目标变量的总体预测能力的指标，它是所有分箱的 WOE 值的加权和，其计算公式如下。

所以 IV 值实际上衡量的是好客户和坏客户在各分箱中分布差异的加权总和，权重就是各分箱的 WOE 值，差异越大，权重越大，IV 值就越高。而 IV 值越高，说明该特征对区分好坏客户的能力越强，通常 IV 值的评判标准如下。

• < 0.02：无预测能力

• 0.02 ~ 0.15：预测能力正常。

• 0.15 ~ 0.3：预测能力强

• 0.3 ~ 0.4：预测能力极强（需要警惕过拟合）

• > 0.4：直接看是不是过拟合了

举个例子，假设我们对特征 "月收入" 进行分箱，得到以下结果。

显然 IV 值等于 (17.8% - 40%) * -0.81 + (50% - 50%) * 0 + (32.2% - 10%) * 1.17 = 0.44，而 0.44 表示月收入这个特征具有极强的预测能力（当然 0.44 过于高了，这里只是随便举例）。而通过观察 WOE 值，也可以证明这一点。

• < 5000元：WOE = -0.811 < 0，高风险群体。

• 5000 ~ 10000元：WOE = 0，风险中性。

• > 10000元：WOE = 1.173 > 0，低风险群体。

这个结果符合业务直觉，收入越高，信用风险越低。

然后是 IV 值的大小问题，我们说 IV 值如果大于 0.4 反而是个不好的现象，因为大于 0.4 表示特征和目标结果拟合的太完美了，这说明了以下几个问题。

• 数据泄露：变量可能包含了未来信息或与目标变量直接相关的信息。

• 样本偏差：训练样本可能存在某种特殊的数据分布，不能代表真实总体。

• 数据质量问题：变量定义不当，可能直接或间接包含了标签信息。

0.1 ~ 0.4 通常是 IV 值最理想的范围，既有足够的预测能力，又保持了良好的稳定性和可解释性。"适度" 往往比 "极端" 更可靠，这在风控建模中尤其重要。

另外可能有人会产生误区，还是不理解为什么 IV 值不能太大，这是因为我们说的都是单个特征的 IV 值。而单个特征本身就只能解释数据的一部分信息，任何单一维度都无法完全刻画客户的信用风险。

而实际的特征工程中，客户会有大量特征，每个特征都有对应的 IV 值。通过多个特征组合，不同特征捕获不同维度的信息，并且特征之间存在互补，从而实现预测能力远超单个特征。

• 收入高 + 年龄大 + 工作稳定 → 低风险

• 收入高 + 年龄小 + 工作不稳定 → 中等风险

• 收入低 + 年龄大 + 工作稳定 → 中等风险

• 收入低 + 年龄小 + 工作不稳定 → 高风险

如果一个特征就能实现精准预测，那还要其它特征做什么？如果出现这样的特征（IV 值超过了 0.4、甚至更大），那么就要好好检测一下是不是出现了过拟合现象。

假设有以下几个特征。

组合后的效果：

• 4  个特征组合：AUC 可能达到 0.75 ~ 0.80。

• 10 个特征组合：AUC 可能达到 0.80 ~ 0.85。

• 50 个特征组合：AUC 可能达到 0.85 ~ 0.90。

所以在实际建模时，我们更关注特征组合后的整体效果，不会因为某个特征 IV 只有 0.15 就丢弃。宁可选择 10 个 IV=0.2 的不同维度特征，也不选择 3 个 IV=0.4 但高度相关的特征。

关于 IV 值，我们要记住以下几个结论。

• IV 是筛选工具，不是绝对标准。

• 特征组合的整体效果比单个特征更重要。

• 多维度的中等强度特征组合往往比少数高 IV 特征的效果更好。

• 最终评判标准是模型在验证集上的综合表现。

这就是为什么经验丰富的风控建模师会说："特征工程是艺术，不只是科学"。

既然提到了 IV 值，那么继续补充一下它在建模时的应用。

在实际的特征工程中，会为每个客户刻画数万（甚至数十万、数百万）个特征，然后用这些特征来建模。但如果特征过多，不仅耗费资源，甚至一些无用特征反而会降低准确率，那么这时候就要进行特征筛选，从数万个特征中筛选出最有用的部分特征。而 "最有用" 三个字的量化方式就是通过 IV 值，IV 值越大，说明它对样本预测的重要性越大。

和 PCA 降维的关系

有过机器学习经验的朋友会发现，整个过程就类似于 PCA 降维，因为不是所有特征都是有用的。而 PCA 会将原始数据映射到新的空间，每个轴都是原始特征的加权组合，如果该轴的可解释方差比例越大，证明这个轴就越有用。当然一个轴是不够的，我们需要可解释方差比例最大的 k 个轴，如果它们的可解释方差比例加起来接近 1，那么只需要这 k 个轴即可。

因此通过 PCA 降维，将具有 n 个特征的原始数据映射到新的空间之后，只需 k 个特征即可进行预测，并且 k 是远小于 n 的。而建模这个过程与之类似，虽然原理不一样，但做的事情是一样的，也是从全量特征中筛选出部分最有用的特征，只是量化标准是 IV 值。

那么问题来了，为啥不用 PCA 降维呢？原因有以下几个。

1）监管合规要求

监管机构如果问，为什么拒绝这个客户的贷款申请？

• PCA 降维：因为他的 xx 值较低 …（无法解释）

• 特征筛选：因为他的月收入过低且信用卡使用率过高（可解释）

2）业务策略制定

• PCA 方法：xx < -0.5 且 yy > 1.2 的客户需要额外审核（难以操作）

• 传统方法：月收入 < 5000 且年龄 < 25 岁的客户需要额外审核（易操作）

3）模型监控和调试

• 当模型表现下降时，可以直接分析具体特征的变化

• 容易发现数据漂移和特征失效

所以无论是 PCA 降维还是 IV 值筛选，本质都是在高维空间中寻找最有价值的信息维度。PCA 是通过寻找方差最大的方向，而 IV 值筛选是寻找与目标最相关的特征，两者做的事情都是在有限的维度预算下，最大化保留信息。

但在金融风控场景下，可解释性往往比信息压缩更重要，所以过滤特征时会使用 IV 值筛选，而不是 PCA 降维。

如何通过 IV 值实现特征筛选

好，再来看看通过 IV 值实现特征筛选的具体流程。

第一阶段：数据准备与预处理

1）原始数据质量检查

统计每个特征的缺失率、唯一值数量、数据类型，识别常数列（所有值都相同的特征），检查数据分布的基本情况。

2）基础数据清晰

剔除缺失率过高的特征（通常 > 80%），删除方差过小的数值型特征（几乎没有变化），移除唯一值过少的特征（如只有 1 ~ 2 个取值）。

第二阶段：特征分箱处理

如果是数值型特征：对于每个特征进行分箱，一般选择卡方分箱，并且确保每个分箱有足够的样本量（通常要求每箱 > 5%总样本）。检查分箱后的单调性，每个箱的 WOE 值应该单调递增或递减。

如果是非数值型（字符串）特征：将该特征可能出现的值进行分类，每个类别也要有足够的样本量。如果是非常少见的值，那么整体合并为 "其它"。

第三阶段：IV 值批量计算

按照 WOE 和 IV 的公式，为每个特征计算 IV 值。并且在此过程中，要记录出现的异常情况（如某个分箱没有正样本或负样本），并且建立详细的计算日志，便于后续排查问题。

然后将所有特征的 IV 值汇总到一张表中，按 IV 值从高到低排序，统计不同 IV 值区间的特征数量分布。

第四阶段：多层次特征筛选

1）IV 阈值筛选

设置 IV 值的上下限，剔除 IV 值过低的特征（预测能力不足），标记 IV 值过高的特征（可能存在数据问题）。

2）可疑特征检查

对 IV 值大于 0.3 的特征进行深度检查，主要包含以下方面。

• 数据泄露检查：是否包含未来信息或目标变量的直接信息。

• 业务合理性验证：特征与目标变量的关系是否符合业务逻辑。

• 时间稳定性验证：在不同时间段上 IV 值是否稳定。

• 样本分布检查：是否存在极端的样本分布导致 IV 值虚高。

3）特征多样性保证

确保不同业务维度的特征都有覆盖（如收入、年龄、信用历史等），避免选择的特征过于集中在某个业务领域，平衡高 IV 特征和中等 IV 特征的数量。

第五阶段：特征稳定性验证

1）时间稳定性测试

在不同的时间窗口上重新计算 IV 值，检查 IV 值的波动幅度（波动 < 20% 认为稳定），剔除在不同时期表现差异过大的特征。

2）跨样本验证

在训练集、验证集、测试集上分别计算 IV 值，确保特征的预测能力不是因为某个特定样本导致的。

第六阶段：最终特征集确定

1）将多个维度的评估结果综合

• IV 值大小（权重 40%）

• 稳定性评分（权重 30%）

• 业务重要性评分（权重 20%）

• 数据可得性评分（权重 10%）

2）根据模型类型和业务需求确定最终特征数量

所以整个流程非常清晰：

原始特征 → 基础清洗 → IV 计算 → 初步筛选 → 深度验证 → 稳定性测试 → 最终选择

而筛选标准也很简单：

• 数据质量：缺失率 < 20%，异常值 < 5%

• IV 值合理性：0.02 ≤ IV ≤ 0.4

• 稳定性要求：不同时期 IV 值波动 < 30%

• 业务合理性：特征逻辑符合业务常识

阅读原文

跳转微信打开

我（用 Claude）写了一个抽奖模拟器，随机挑选了 10 位同学。请这些同学私信我地址+姓名+手机号，我联系极客时间给你们赠书。

我（用 Claude）写了一个抽奖模拟器，随机挑选了 10 位同学。

请这些同学私信我地址+姓名+手机号，我联系极客时间给你们赠书。

本人在此声明：你们的信息绝不会泄露，只会拷贝发给极客时间的工作人员，由他们负责赠书。

至于具体的抽奖过程，我录制了一个视频，本人承诺没有任何的暗箱操作。

最后在这里感谢极客时间给大家赠与的福利，如果大家想学习技术，也请多多支持极客时间，里面不仅有海量的技术专栏，并且价格实惠，福利多多哦。

阅读原文

跳转微信打开

不得不说，极客时间真是最懂程序员的！最近新项目里碰到一堆AI难题，正发愁呢，结果发现他们出了《AI 百问百答》📚100+ AI 热点问题，50+专家解答。

不得不说，极客时间真是最懂程序员的！最近新项目里碰到一堆AI难题，正发愁呢，结果发现他们出了《AI 百问百答》

📚100+ AI 热点问题，50+专家解答。

🎓线上课程+配套实体书，两种方式任选领取：

• 19.9元直接购买，省时省力，戳 http://gk.link/a/12Ao8 

• 邀请5位好友助力，0元到手，戳 http://gk.link/a/12As9

  
  

或者还有第三种方式，评论区留言点赞抽 10 位朋友免费送，1 人 1 本。

阅读原文

跳转微信打开

车祸是不幸的，愿白女士能早日康复。

当然我发这篇文章主要是为了回答后台的一些私信，兄弟们不要再问我啥时候更新技术文章了，更不下去了。你能想象吗，一个不懂 Vue 的人，一行 Vue 代码没写，靠着和 Claude Code 聊聊天，就能用 Vue 搭建一个具有一定规模的前端项目。

这太可怕了，前端如此，后端也好不到哪里去。AI 大模型的出现，让技术这条护城河轰然决堤。虽说近几年大环境差，但前两年我是不担心的，不过现在也有点蕉绿了。

最后，祝大家都能把 AI 用起来，抓住风口（话说目前还有风口吗）。

跳转微信打开

鸡哥是一个优秀且苦逼的程序员，每天都被领导无情地摧残着，就在他感觉身体即将被掏空时，领导又让他充当交际花，利用

鸡哥是一个优秀且苦逼的程序员，每天都被领导无情地摧残着，就在他感觉身体即将被掏空时，领导又让他充当交际花，利用美色从某个女老板手里拿到投资。正所谓工欲善其事，必先利其器，领导给鸡哥一份文档，是从女老板秘书手里买来的，里面记录了女老板近一年的生活轨迹等，让鸡哥在脑海中构建女老板的画像。

没过多久，女老板要求在饭桌上洽谈合作的事情，那么鸡哥自然要打扮一番，可是该穿什么样的衣服呢？于是他询问大语言模型。

阅读原文

跳转微信打开

今天早上醒来，有群友给我反馈说群没了，我一看还在啊，难道说···果然，群虽然还在，但每个人发的消息，其他人都看

今天早上醒来，有群友给我反馈说群没了，我一看还在啊，难道说···

果然，群虽然还在，但每个人发的消息，其他人都看不到，可以认为群没了。至于没的原因，相信大家也能猜出来。

任何一个交流群，一开始大家都讨论技术，但到最后都会无可避免地变成吹水群，里面充斥着打拳和键政。当然很大一部分原因在我，因为我基本不怎么管理。

至于新群我就不建了，愿各位群友都生活幸福、工作顺利。

阅读原文

跳转微信打开

我之前的源码剖析、用 C 写 Python、以及 Cython 系列都放在 github 上面了，这些算是比较

阅读原文

跳转微信打开

不管什么模型，文字和手永远都是重灾区，要么手指头的长度比例不对，要么就是 6 根、甚至 7 根手指头。

那么多好看的图片，就因为手部特征的问题，直接 GG。

GPU 都快跑冒烟了。。。。。。

跳转微信打开

"可爱吗？"

"可爱"

"恋上了吗？"

"怎么理解这几个字，是 s[0: 1]，s[1: ]，还是 s[:]，我不懂唉"

"我问你恋上她了吗？"

"OK，恋上了"

\x22可爱吗？\x22

\x22可爱\x22

\x22恋上了吗？\x22

\x22怎么理解这几个字，是 s[0: 1]，s[1: ]，还是 s[:]，我不懂唉\x22

\x22我问你恋上她了吗？\x22

\x22OK，恋上了\x22

跳转微信打开

卷 Python 容易饿死。

阅读原文

跳转微信打开

• 公众号会对图片进行压缩，本来图片是高清的，结果上传之后就变模糊了。
• 公众号用于展示内容的区域太窄了，当一张图片的元素比较多时，根本看不清。
  
  

• 用 C 写 Python
• Cython 从入门到精通
• CPython 源码探秘
  
  

阅读原文

跳转微信打开

我之前向大家介绍了某个神奇的物种，这里再把原因解释一下。有个网名叫 chao 的人，自称超哥，在我的群里引战。由于我当初不怎么看群，中间也只是简单劝过他，直到后面越来越多的人被他气到退群，我没办法，只能将他移出群聊，移出的时候还说了句抱歉。

本来是一件非常简单的事情，但他莫名对我产生了恨意，特别是当我整了个付费合集之后，在后台私信追着我骂。

类似的记录还有一大堆，更加的污言秽语，这些我就不贴了。至于我当初为什么不拉黑他，主要是我想看看一个人能莫名产生多大的恨意。另外我也一直在跟他复盘，希望他能明白整个事情的经过，但他似乎只专注于骂人。

如果只是简单的脏话，我倒还无所谓，关键的是它一直在污蔑我，说我教唆别人骂他，说我干了很多黑心事，问题是我怎么不知道。

当然以上这些都不是重点，重点是它说要发文章打败我。

他之前评论也说了，要让大家明白我的文章其实一文不值。听到这句话我还挺开心的，我也好奇并期待他能写出什么样的文章，但是之后就没影了······。

它还建立了一个微信群，我有一个群友加进去了，这是它的豪言壮语。

现如今已经 4 个月过去了，它依旧没什么动静，并且说完这话没几天，群友就被踢出去了？？？？？？

可能是我和这个人之间产生了深厚的感情，昨晚睡觉的时候想起来自己还没有介绍生成器，今天专门请了半天假，把文章肝出来了。超哥没有完成的事情，就由我来替他完成吧，毕竟谢幕的时候，它作为主角应该站在舞台上，闪闪发光，熠熠生辉。

❤️守护全世界最好的超哥❤️

❤️即使全世界都抛弃了你❤️

❤️我也会坚定的❤️

❤️和全世界站在一起❤️

楔子

本次来聊一聊 Python 的生成器，它是我们后续理解协程的基础（对不起，没有后续了）。生成器的话，估计大部分人在写程序的时候都不怎么用，但其实生成器一旦用好了，确实能给程序带来性能上的提升，那么下面就来看一看吧。

生成器的基础知识

我们知道，如果函数的内部出现了 yield 关键字，那么它就不再是普通的函数了，而是一个生成器函数，调用之后会返回一个生成器对象。

生成器对象一般用于处理循环结构，应用得当的话可以极大优化内存使用率。比如：我们读取一个大文件。

def read_file(file):
    return open(file, encoding="utf-8").readlines()
print(read_file("假装是大文件.txt"))
"""
['人生是什么?\n', '大概是闪闪发光的同时\n', '又让人感到痛苦的东西吧']
"""

这个版本的函数，直接将里面的内容全部读取出来了，返回了一个列表。如果文件非常大，那么内存的开销可想而知。于是我们可以通过 yield 关键字，将普通函数变成一个生成器函数。

from typing import Iterator, Generator
def read_file(file):
    with open(file, encoding="utf-8") as f:
        for line in f:
            yield line
data = read_file("假装是大文件.txt")
# 返回一个生成器对象
print(data)
"""
<generator object read_file at 0x0000019B4FA8BAC0>
"""
# 使用 for 循环遍历
for line in data:
    # 文件每一行自带换行符, 所以这里的 print 就不用换行符了
    print(line, end="")
"""
人生是什么?
大概是闪闪发光的同时
又让人感到痛苦的东西吧
"""

由于生成器是一种特殊的迭代器，所以也可以使用它的 __next__ 方法。

def gen():
    yield 123
    yield 456
    yield 789
    return "result"
# 调用生成器函数时，会创建一个生成器
# 生成器虽然创建了，但是里面的代码并没有执行
g = gen()
# 调用 __next__ 方法时才会执行
# 当遇到 yield，会将生成器暂停、并返回 yield 后面的值
print(g.__next__())  # 123
# 此时生成器处于暂停状态，如果我们不驱动它的话，它是不会前进的
# 再次执行 __next__，生成器恢复执行，并在下一个 yield 处暂停
print(g.__next__())  # 456
# 生成器会记住自己的执行进度，它总是在遇到 yield 时暂停
# 调用 __next__ 时恢复执行，直到遇见下一个 yield
print(g.__next__())  # 789
# 显然再调用 __next__ 时，已经找不到下一个 yield 了
# 那么生成器会抛出 StopIteration，并将返回值设置在里面
try:
    g.__next__()
except StopIteration as e:
    print(f"返回值：{e.value}")  # 返回值：result

可以看到，基于生成器，我们能够实现惰性求值。

当然啦，生成器不仅仅有 __next__ 方法，它还有 send 和 throw 方法，我们先来说一说 send。

def gen():
    res1 = yield "yield 1"
    print(f"***** {res1} *****")
    res2 = yield "yield 2"
    return res2
g = gen()
# 此时程序在第一个 yield 处暂停
print(g.__next__())
"""
yield 1
"""
# 调用 g.send(val) 依旧可以驱动生成器执行
# 同时还可以传递一个值，交给第一个 yield 左边的 res1
# 然后寻找第二个 yield
print(g.send("嘿嘿"))
"""
***** 嘿嘿 *****
yield 2
"""
# 上面输出了两行，第一行是生成器里面的 print 打印的
try:
    # 此时生成器在第二个 yield 处暂停，调用 g.send 驱动执行
    # 同时传递一个值交给第二个 yield 左边的 res2，然后寻找第三个 yield
    # 但是生成器里面没有第三个 yield 了，于是抛出 StopIteration
    g.send("蛤蛤")
except StopIteration as e:
    print(f"返回值：{e.value}")
"""
返回值：蛤蛤
"""

生成器永远在 yield 处暂停，并将 yield 后面的值返回。如果想驱动生成器继续执行，可以调用 __next__ 或 send，会去寻找下一个 yield，然后在下一个 yield 处暂停。依次往复，直到找不到 yield 时，抛出 StopIteration，并将返回值包在里面。

但是这两者的不同之处在于，send 可以接收参数，假设生成器在 res = yield 123 这里停下来了。

当调用 __next__ 和 send 的时候，都可以驱动执行，但调用 send 时可以传递一个 value，并将 value 赋值给变量 res。而 __next__ 没有这个功能，如果是调用 __next__ 的话，那么 res 得到的就是一个 None。

所以 res = yield 123 这一行语句需要两次驱动生成器才能完成，第一次驱动会让生成器执行到 yield 123，然后暂停执行，将 123 返回。第二次驱动才会给变量 res 赋值，此时会寻找下一个 yield 然后暂停。

生成器的预激

刚创建生成器的时候，里面的代码还没有执行，它的 f_lasti 是 -1。关于什么是 f_lasti，需要解释一下。

首先随着 CPython 版本的升级，一些数据结构的底层实现也在发生改变，比如栈帧等等。在之前的版本中，栈帧有一个字段叫 f_lasti，它表示最近一条执行完毕的字节码指令的偏移量。而在 3.12 里面，这个字段已经没了。

虽然解释器内部结构会发生变化，但暴露出来的 Python 接口是不变的，所以我们依旧可以访问该字段。

def gen():
    res1 = yield 123
    res2 = yield 456
    return "result"
g = gen()
# 生成器函数和普通函数一样，执行时也会创建栈帧
# 通过 g.gi_frame 可以很方便的获取
print(g.gi_frame.f_lasti)  # -1

f_lasti 是 -1，表示生成器刚被创建，还没有执行任何指令。而第一次驱动生成器执行，叫做生成器的预激。但在生成器还没有被预激时，我们调用 send，里面只能传递一个 None，否则报错。

def gen():
    res1 = yield 123
    res2 = yield 456
    return "result"
g = gen()
try:
    g.send("小云同学")
except TypeError as e:
    print(e)
"""
can't send non-None value to a just-started generator
"""

对于尚未被预激的生成器，我们只能传递一个 None，也就是 g.send(None)。或者调用 g.__next__()，因为不管何时它传递的都是 None。

其实也很好理解，我们之所以传值是为了赋给 yield 左边的变量，这就意味着生成器必须至少被驱动一次、在某个 yield 处停下来才可以。而未被预激的生成器，它里面的代码压根就没有执行，所以第一次驱动的时候只能传递一个 None 进去。

如果查看生成器的源代码的话，也能证明这一点：

在之前的版本中，判断条件是 f_lasti 是否等于 -1，而在 3.12 中引入了 gi_frame_state 字段，表示生成器的状态。如果生成器刚创建，并且接收的参数 arg 不为 None，那么报错。

那么生成器的状态都有哪些呢？

// Include/internal/pycore_frame.h
typedef enum _framestate {
    FRAME_CREATED = -2,
    FRAME_SUSPENDED = -1,
    FRAME_EXECUTING = 0,
    FRAME_COMPLETED = 1,
    FRAME_CLEARED = 4
} PyFrameState;

状态总共有五种。

• FRAME_CREATED：生成器刚创建。

• FRAME_SUSPENDED：生成器被挂起，也就是执行到某个 yield 之后返回了。

• FRAME_EXECUTING：生成器执行中。

• FRAME_COMPLETED：生成器执行完毕，但栈帧对象还未被清理。

• FRAME_CLEARED：生成器的栈帧对象被清理。

  
  

相关源码细节下一篇文章（对不起，没有下一篇了）会分析。

生成器的 throw 方法

除了 __next__ 和 send 方法之外，生成器还有一个 throw 方法，该方法的作用和前两者类似，也是驱动生成器执行，并在下一个 yield 处暂停。但它在调用的时候，需要传递一个异常进去。

def gen():
    try:
        yield 123
    except ValueError as e:
        print(f"异常：{e}")
    yield 456
    return "result"
g = gen()
# 生成器在 yield 123 处暂停
g.__next__()
# 向生成器传递一个异常
# 如果当前生成器的暂停位置处无法捕获传递的异常，那么会将异常抛出来
# 如果能够捕获，那么会驱动生成器执行，并在下一个 yield 处暂停
# 当前生成器位于 yield 123 处，而它所在的位置能够捕获异常
# 所以不会报错，结果就是 456 会赋值给 val
val = g.throw(ValueError("一个 ValueError"))
"""
异常：一个 ValueError
"""
print(val)
"""
456
"""

关于生成器的 __next__、send、throw 三个方法的用法我们就说完了，还是比较简单的。

关闭生成器

生成器也是可以关闭的，我们来看一下。

def gen():
    yield 123
    yield 456
    return "result"
g = gen()
# 生成器在 yield 123 处停止
print(g.__next__())  # 123
# 关闭生成器
g.close()
# 生成器一旦关闭，就代表执行完毕了，它的栈帧会被重置为 None
print(g.gi_frame)  # None
try:
    # 再次调用 __next__，会抛出 StopIteration
    g.__next__()
except StopIteration as e:
    # 此时 e.value 为 None
    print(e.value)  # None

无论是显式地关闭生成器，还是正常情况下生成器执行完毕，内部的栈帧都会被重置为 None。而驱动一个已经执行结束的生成器，会抛出 StopIteration 异常，并且异常的 value 属性为 None。

GeneratorExit 异常

这里再来说一说 GeneratorExit 这个异常，如果我们关闭一个生成器（或者生成器被删除时），那么会往里面扔一个 GeneratorExit 进去。

def gen():
    try:
        yield 123
    except GeneratorExit as e:
        print("生成器被删除了")
g = gen()
# 生成器在 yield 123 处暂停
g.__next__()
# 关闭生成器，会往里面扔一个 GeneratorExit
g.close()
"""
生成器被删除了
"""

这里我们捕获了传递的 GeneratorExit，所以 print 语句执行了，但如果没有捕获呢？

def gen():
    yield 123
g = gen()
g.__next__()
g.close()

此时无事发生，但是注意：如果是手动调用 throw 方法扔一个 GeneratorExit 进去，异常还是会抛出来的。

那么问题来了，生成器为什么要提供这样一种机制呢？直接删就完了，干嘛还要往生成器内部丢一个异常呢？答案是为了资源的清理和释放。

在 Python 还未提供原生协程，以及 asyncio 还尚未流行起来的时候，很多开源的协程框架都是基于生成器实现的协程。而创建连接的逻辑，一般都会写在 yield 后面。

def _create_connection():
    # 一些逻辑
    yield conn
    # 一些逻辑

但是这些连接在不用的时候，要不要进行释放呢？答案是肯定的，所以便可以这么做。

def _create_connection():
    # 一些逻辑
    try: 
        yield conn
    except GeneratorExit:
        conn.close()
    # 一些逻辑

这样当我们关闭或删除生成器的时候，就能够自动对连接进行释放了。

不过还有一个需要注意的点，就是在捕获 GeneratorExit 之后，不可以再执行 yield，否则会抛出 RuntimeError。

def gen():
    try:
        yield 123
    except GeneratorExit:
        print("生成器被删除")
        yield
g = gen()
g.__next__()
g.close()
"""
生成器被删除
Traceback (most recent call last):
  File "...", line 10, in <module>
    g.close()
RuntimeError: generator ignored GeneratorExit
"""

调用 close 方法时，如果没有成功捕获 GeneratorExit，那么生成器会直接关闭，不会有任何事情发生。但如果捕获了 GeneratorExit，那么可以在对应的语句块里做一些资源清理逻辑，但不应该再出现 yield。

而上面的例子中出现了 yield，所以解释器会抛出 RuntimeError，因为没捕获 GeneratorExit 还好，解释器不会有什么抱怨。但如果捕获了 GeneratorExit，说明我们知道生成器是被关闭了，既然知道，那里面还出现 yield 的意义何在呢？

当然啦，如果出现了 yield，但没有执行到，则不会抛 RuntimeError。

def gen():
    try:
        yield 123
    except GeneratorExit:
        print("生成器被删除")
        return
        yield
g = gen()
g.__next__()
g.close()
print("------------")
"""
生成器被删除
------------
"""

遇见 yield 之前就返回了，所以此时不会出现 RuntimeError。

注意：GeneratorExit 继承自 BaseException，它无法被 Exception 捕获。

yield from 的用法

当函数内部出现了 yield 关键字，那么它就是一个生成器函数，对于 yield from 而言亦是如此。那么问题来了，这两者之间有什么区别呢？

from typing import Generator
def gen1():
    yield [1, 2, 3]
def gen2():
    yield from [1, 2, 3]
g1 = gen1()
g2 = gen2()
# 两者都是生成器
print(isinstance(g1, Generator))  # True
print(isinstance(g2, Generator))  # True
print(g1.__next__())  # [1, 2, 3]
print(g2.__next__())  # 1

结论很清晰，yield 对后面的值没有要求，会直接将其返回。而 yield from 后面必须跟一个可迭代对象（否则报错），然后每次返回可迭代对象的一个值。

def gen():
    yield from [1, 2, 3]
    return "result"
g = gen()
print(g.__next__())  # 1
print(g.__next__())  # 2
print(g.__next__())  # 3
try:
    g.__next__()
except StopIteration as e:
    print(e.value)  # result

除了要求必须跟一个可迭代对象，然后每次只返回一个值之外，其它表现和 yield 是类似的。而对于当前这个例子来说，yield from [1, 2, 3] 等价于 for item in [1, 2, 3]: yield item。

所以有人觉得 yield from 貌似没啥用啊，它完全可以用 for 循环加 yield 进行代替。很明显不是这样的，yield from 背后做了非常多的事情，我们稍后说。

这里先出一道思考题：

这时候便可以通过 yield 和 yield from 来实现这一点。

def flatten(data):
    for item in data:
        if isinstance(item, list):
            yield from flatten(item)
        else:
            yield item
data = [1, [[[[[3, 3], 5]]], [[[[[[[[[[[[6]]]]], 8]]], "aaa"]]]], 250]]
print(list(flatten(data)))  # [1, 3, 3, 5, 6, 8, 'aaa', 250]

怎么样，是不是很简单呢？

委托生成器

如果单从语法上来看的话，会发现 yield from 貌似没什么特殊的地方，但其实 yield from 还可以作为委托生成器。委托生成器会在调用方和子生成器之间建立一个双向通道，什么意思呢？我们举例说明。

def gen():
    yield 123
    yield 456
    return "result"
def middle():
    res = yield from gen()
    print(f"接收到子生成器的返回值: {res}")
# middle 里面出现了 yield from gen()
# 此时 middle() 便是委托生成器，gen() 是子生成器
g = middle()
# 而 yield from 会在调用方和子生成器之间建立一个双向通道
# 两者是可以互通的，调用 g.send、g.throw 都会直接传递给子生成器
print(g.__next__())  # 123
print(g.__next__())  # 456
# 问题来了，如果再调用一次 __next__ 会有什么后果呢？
# 按照之前的理解，应该会抛出 StopIteration
print(g.__next__())
"""
接收到子生成器的返回值: result
Traceback (most recent call last):
  File "...", line 21, in <module>
    print(g.__next__())
StopIteration
"""

在第三次调用 __next__ 的时候，确实抛了异常，但是委托生成器收到了子生成器的返回值。也就是说，委托生成器在调用方和子生成器之间建立了双向通道，两者是直接通信的，并且当子生成器出现 StopIteration 时，委托生成器还要负责兜底。

委托生成器会将子生成器抛出的 StopIteration 里面的 value 取出来，然后赋值给左侧的变量 res，并在自己内部继续寻找 yield。

换句话说，当子生成器 return 之后，委托生成器会拿到返回值，并将子生成器抛出的异常给捕获掉。但是还没完，因为还要找到下一个 yield，那么从哪里找呢？显然是从委托生成器的内部寻找，于是接下来就变成了调用方和委托生成器之间的通信。

如果在委托生成器内部能找到下一个 yield，那么会将值返回给调用方。如果找不到，那么就重新构造一个 StopIteration，将异常抛出去。此时异常的 value 属性，就是委托生成器的返回值。

def gen():
    yield 123
    return "result"
def middle():
    res = yield from gen()
    return f"委托生成器返回了子生成器的返回值：{res}"
g = middle()
print(g.__next__())  # 123
try:
    g.__next__()
except StopIteration as e:
    print(e.value)  # 委托生成器返回了子生成器的返回值：result

大部分情况下，我们并不关注委托生成器的返回值，我们更关注的是子生成器。于是可以换种写法：

def gen():
    yield 123
    yield 456
    yield 789
    return "result"
def middle():
    yield (yield from gen())
g = middle()
for v in g:
    print(v)
"""
123
456
789
result
"""

所以委托生成器负责在调用方和子生成器之间建立一个双向通道，通道一旦建立，调用方可以和子生成器直接通信。虽然调用的是委托生成器的 __next__、send、throw 等方法，但影响的都是子生成器。

并且委托生成器还可以对子生成器抛出的 StopIteration 异常进行兜底，会捕获掉该异常，然后拿到返回值，这样就无需手动捕获子生成器的异常了。但问题是委托生成器还要找到下一个 yield，并将值返回给调用方，此时这个重担就落在了它自己头上。

如果找不到，还是要将异常抛出来的，只不过抛出的 StopIteration 是委托生成器构建的。而子生成器抛出的 StopIteration，早就被委托生成器捕获掉了。于是我们可以考虑在 yield from 的前面再加上一个 yield，这样就不会抛异常了。

为什么要有委托生成器

我们上面已经了解了委托生成器的用法，不过问题来了，这玩意为啥会存在呢？上面的逻辑，即便不使用 yield from 也可以完成啊。

其实是因为我们上面的示例代码比较简单（为了演示用法），当需求比较复杂时，将生成器内部的部分操作委托给另一个生成器是有必要的，这也是委托生成器的由来。

而委托生成器不仅要能保证调用方和子生成器之间直接通信，还要能够以一种优雅的方式获取子生成器的返回值，于是新的语法 yield from 就诞生了。

但其实 yield from 背后为我们做得事情还不止这么简单，它不单单是建立双向通道、获取子生成器的返回值，它还会处理子生成器内部出现的异常，详细内容可以查看 PEP380。

https://peps.python.org/pep-0380/

这里我们直接给出结论，并通过代码演示一下。

1）子生成器 yield 后面的值，会直接返回给调用方；调用方 send 发送的值，也会直接传给子生成器。

def gen():
    res = yield 123
    yield [res]
    return "result"
def middle():
    yield (yield from gen())
g = middle()
# 子生成器 yield 后面的值，会直接返回给调用方
print(g.__next__())  # 123
# 调用方 send 发送的值，也会直接传给子生成器
print(g.send("小云同学"))  # ['小云同学']

另外还要补充一个细节，如果 yield from 一个已经消耗完毕的生成器，会直接返回 None。

def gen():
    yield 123
    return "result"
def middle():
    sub = gen()
    res = yield from sub
    yield res + " from gen()"
    # 到这里的话，sub = gen() 这个生成器已经被消耗完毕了
    # 如果我们继续 yield from 的话，会直接返回 None
    res = yield from sub
    yield f"res: {res}"
g = middle()
print(g.__next__())  # 123
print(g.__next__())  # result from gen()
# 此处执行 g.__next__() 时
# 委托生成器内部会执行第二个 res = yield from sub
# 但问题是 sub 之前就已经被消耗完了，所以会直接返回 None，然后寻找下一个 yield
print(g.__next__())  # res: None

所以不要对生成器做二次消费。

2）子生成器结束时，最后的 return value 等价于 raise StopIteration(value)。然后该异常会被 yield from 捕获，并将 value 赋值给 yield from 左侧的变量。并且在拿到子生成器的返回值时，委托生成器会继续运行，寻找下一个 yield。

def gen():
    yield 123
    return "result"
def middle():
    res = yield from gen()
    yield res + " from middle()"
g = middle()
print(g.__next__())  # 123
# 子生成器 gen() 在 return 时会抛出 StopIteration
# 然后在委托生成器内部被捕获，并将返回值赋给 res
# 接着继续寻找下一个 yield
print(g.__next__())  # result from middle()

另外补充一点，生成器在 return 时，等价于抛出一个 StopIteration。但异常必须在 return 的时候隐式抛出，如果是在生成器内部 raise StopIteration 则是不合法的。

def gen():
    yield 123
    raise StopIteration("result")
g = gen()
print(g.__next__())  # 123
print(g.__next__())
"""
Traceback (most recent call last):
  File "......", line 3, in gen
    raise StopIteration("result")
StopIteration: result
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
  File "......", line 7, in <module>
    print(g.__next__())
RuntimeError: generator raised StopIteration
"""

此时会引发一个 RuntimeError。

3）如果子生成器在执行的过程中，内部出现了异常，那么会将异常丢给委托生成器。委托生成器会尝试处理该异常，如果处理不了，那么再调用子生成器的 throw 方法将异常扔回去。

def gen():
    yield 123
    raise ValueError("出了个错")
    return "result"
def middle():
    yield from gen()
g = middle()
print(g.__next__())  # 123
# 此时子生成器会抛出 ValueError，而委托生成器没有异常捕获逻辑，无法处理
# 于是会调用子生成器的 throw 方法，将异常重新扔回去，最终由调用方来处理
try:
    print(g.__next__())  # 123
except ValueError as e:
    print(e)  # 出了个错

那如果委托生成器可以处理子生成器抛出的异常呢？

def gen():
    yield 123
    raise ValueError("出了个错")
    return "result"
def middle():
    try:
        yield from gen()
    except ValueError as e:
        yield f"异常：{e}"
    # 当子生成器抛出异常时，它就已经结束了
    yield "result from middle()"
g = middle()
print(g.__next__())  # 123
print(g.__next__())  # 异常：出了个错
print(g.__next__())  # result from middle()

如果委托生成器可以处理子生成器抛出的异常，那么接下来就是调用方和委托生成器之间的事情了。

再比如我们将生成器 close 掉，看看结果会怎样，我们知道它会 throw 一个 GeneratorExit。

def gen():
    yield 123
    return "result"
def middle():
    try:
        yield from gen()
    except GeneratorExit as e:
        print(f"子生成器结束了")
g = middle()
print(g.__next__())  # 123
# 关闭子生成器，会 throw 一个 GeneratorExit
# 然后这个 GeneratorExit 会向上透传给委托生成器
g.close()
"""
子生成器结束了
"""
# 注意：委托生成器也是同理
# 一旦捕获了 GeneratorExit，后续不应该再出现 yield

yield from 算是 Python 里面特别难懂的一个语法了，但如果理解了 yield from，后续理解 await 就会简单很多。

生成器表达式

Python 里面还有一个生成器表达式，我们来看一下。

from typing import Generator
g = (x for x in range(10))
print(isinstance(g, Generator))  # True
print(g)  # <generator object <genexpr> at 0x...>
print(g.__next__())  # 0
print(g.__next__())  # 1

如果表达式是在一个函数里面，那么生成器表达式周围的小括号可以省略掉。

import random
d = [random.randint(1, 10) for _ in range(100)]
# 我们想统计里面大于 5 的元素的总和
# 下面两种做法都是可以的
print(
    sum((x for x in d if x > 5)),
    sum(x for x in d if x > 5)
)  # 397 397

这两种做法是等价的，字节码完全一样。

但要注意，生成器表达式还存在一些陷阱，一不小心就可能踩进去。至于是什么陷阱呢？很简单，一句话：使用生成器表达式创建生成器的时候，in 后面的变量就已经确定了，但其它的变量则不会。举个栗子：

g = (巭孬嫑夯烎 for x in [1, 2, 3])

执行这段代码不会报错，尽管 for 前面那一坨我们没有定义，但不要紧，因为生成器是惰性执行的。但如果我们调用了 g.__next__()，那么很明显就会报错了，会抛出 NameError。

g = (x for x in lst)

但是这段代码会报错：NameError: name 'lst' is not defined，因为 in 后面的变量在创建生成器的时候就已经确定好了。而在创建生成器的时候，发现 lst 没有定义，于是抛出 NameError。

所以，陷阱就来了：

i = 1
g = (x + i for x in [1, 2, 3])
i = 10
# 输出的不是 (2, 3, 4)
print(tuple(g))  # (11, 12, 13)

因为生成器只有在执行的时候，才会去确定变量 i 究竟指向谁，而调用 tuple(g) 的时候 i 已经被修改了。

lst = [1, 2, 3]
g = (x for x in lst)
lst = [4, 5, 6]
print(tuple(g))  # (1, 2, 3)

但这里输出的又是 (1, 2, 3)，因为在创建生成器的时候，in 后面的变量就已经确定了，这里会和 lst 指向同一个列表。而第三行改变的只是变量 lst 的指向，和生成器无关。

g = (x for x in [1, 2, 3, 4])
for i in [1, 10]:
    g = (x + i for x in g)
print(tuple(g))

思考一下，上面代码会打印啥？下面进行分析：

• 初始的 g，可以看成是 (1, 2, 3, 4)，因为 in 后面是啥，在创建生成器的时候就确定了；

• 第一次循环之后，g 就相当于 (1+i, 2+i, 3+i, 4+i)；

• 第二次循环之后，g 就相当于 (1+i+i, 2+i+i, 3+i+i, 4+i+i)；

而循环结束后，变量 i 会指向 10，所以打印结果就是 (21, 22, 23, 24)。

生成器与协程

在 Python 还没有引入原生协程的时候，很多开源框架都是基于生成器模拟的协程，最经典的莫过于 Tornado。然而事实上，即便是原生协程，在底层也是基于生成器实现的。

async def native_coroutine():
    return "古明地觉"
try:
    native_coroutine().__await__().__next__()
except StopIteration as e:
    print(e.value)  # 古明地觉

这里没有创建事件循环，而是直接驱动协程执行。我们再演示一段代码，看看让生成器协程和原生协程混合使用会是什么效果。

import asyncio
import time
import types
async def some_task():
    """
    某个耗时较长的任务
    """
    await asyncio.sleep(3)
    return "task result"
async def native_coroutine():
    """
    原生协程
    """
    result = await some_task()
    return f"{result} from native coroutine"
@types.coroutine  # 或者使用 @asyncio.coroutine
def generator_coroutine():
    """
    生成器模拟的协程
    """
    result = yield from some_task()
    return f"{result} from generator coroutine"
async def main():
    start = time.time()
    result = await asyncio.gather(
        native_coroutine(), generator_coroutine()
    )
    end = time.time()
    print(result)
    print(f"耗时：{end - start}")
asyncio.run(main())
"""
['task result from native coroutine', 'task result from generator coroutine']
耗时：3.0016210079193115
"""

从效果上来看，两种方式是等价的。yield from 会驱动协程对象执行，当协程执行 return 的时候，会抛出一个 StopIteration 异常。然后 yield from 再将异常捕获掉，并取出里面的返回值。

但使用装饰器 + yield from 这种方式不够优雅，并且 yield from 即用于生成器，又用于协程，容易给人造成困惑。为此 Python 从 3.5 开始引入了原生协程，使用 async def  定义协程，使用 await 驱动协程执行。

关于协程的更多细节，后续在介绍协程的时候再说，总之我们现在应该使用原生协程，至于 yield from 就让它留在历史的尘埃中吧，我们只需要知道整个演进过程即可。

小结

以上我们就从 Python 的角度梳理了一遍生成器相关的知识，下一篇文章我们将从源码的角度来分析生成器的具体实现。

对不起，没有下一篇了，感谢大家对这个系列的支持。

阅读原文

跳转微信打开

大家好，我是古明地觉，关于 Python 解释器源码剖析系列，我决定暂停更新了，微信豆已经退回。

至于我暂停更新的原因，主要有以下几点。

1）Python 源码有大几十万行，阅读起来真的是费时又费力。再加上随着年纪的增长，琐事越来越多，对技术的热忱也越来越淡，早已不再是刚毕业那会儿了。现在看着密密麻麻的 C 代码，已经没有再阅读下去的动力。

2）研究 Python 解释器注定只是少数人的狂欢，因为这个除了在面试的时候能装一下之外，其实没啥大用，差不多就行了。

3）程序猿如果只会技术的话，其实很难走得长远。按照国内的环境，免不了被裁员。

4）随着 AI 的普及，花大把的时间去研究源码，在现在这个时代已经得不偿失了。

基于以上几个原因，Python 源码剖析系列暂时不更新了，感谢大家一直以来的支持。真的有点累了，读不下去了。

至于我接下来会做什么，现在还没有想好，不过可能会做一些比较有意思、吸引人眼球的话题吧。或者做一些基础内容，以及工作中会经常用到的，分享一些实用工具之类的。Python 解释器源码这种耗费精力的东西真的做不动了o(╥﹏╥)o。

原来的合集已经删除，新的合集链接在这里：Python3.12 源码剖析

阅读原文

跳转微信打开

技术人一定不能和时代脱节，信息差很重要👨‍💻

《极客头条》是专为技术人打造的 免 费 栏目～内容涵盖大模型开发生态、生成式 AI、元宇宙等热点话题。从李彦宏的洞见，到元宇宙的最新动态，这里都有！

📅 周一到周五，每天更新、永久有效，戳此领取：http://gk.link/a/12tye

详细链接可以点击原文链接。

阅读原文

跳转微信打开

装饰器是 Python 的一个亮点，但并不神秘，因为它本质上就是高阶函数加上闭包，只不过给我们提供了一个优雅的语法糖。

至于为什么要有装饰器，我觉得有句话说的非常好，装饰器存在的最大意义就是可以在不改动原函数的代码和调用方式的情况下，为函数增加一些新的功能。

def deco(func):
    print("都闪开，我要开始装饰了")
    def inner(*args, **kwargs):
        print("开始了")
        ret = func(*args, **kwargs)
        print("结束")
        return ret
    return inner
# 这一步等价于 foo = deco(foo)
# 因此上来就会打印 deco 里面的 print
@deco
def foo(a, b):
    print(f"a = {a}，b = {b}")
print("---------")
"""
都闪开，我要开始装饰了
---------
"""
# 此时再调用 foo，已经不再是原来的 foo 了
# 而是 deco 里面的闭包 inner
foo(1, 2)
"""
开始了
a = 1，b = 2
结束
"""

如果不使用装饰器的话：

def deco(func):
    print("都闪开，我要开始装饰了")
    def inner(*args, **kwargs):
        print("开始了")
        ret = func(*args, **kwargs)
        print("结束")
        return ret
    return inner
def foo(a, b):
    print(f"a = {a}，b = {b}")
foo = deco(foo)
"""
都闪开，我要开始装饰了
"""
foo(1, 2)
"""
开始了
a = 1，b = 2
结束
"""

打印结果告诉我们，装饰器只是类似于 foo=deco(foo) 的一个语法糖罢了。

至于字节码这里就不看了，还是那句话，@ 只是个语法糖，它和我们直接调用 foo=deco(foo) 是等价的，所以理解装饰器（decorator）的关键就在于理解闭包（closure）。

另外函数在被装饰器装饰之后，整个函数其实就已经变了，而为了保留原始信息我们一般会从 functools 模块中导入一个 wraps 函数。当然装饰器还可以写的更复杂，比如带参数的装饰器、类装饰器等等，不过这些都属于 Python 层级的东西了，我们就不说了。

另外装饰器还可以不止一个，如果一个函数被多个装饰器装饰，会有什么表现呢？

def deco1(func):
    def inner():
        return f"<deco1>{func()}</deco1>"
    return inner
def deco2(func):
    def inner():
        return f"<deco2>{func()}</deco2>"
    return inner
def deco3(func):
    def inner():
        return f"<deco3>{func()}</deco3>"
    return inner
@deco1
@deco2
@deco3
def foo():
    return "古明地觉"
print(foo())

解释器还是从上到下解释，当执行到 @deco1 的时候，肯定要装饰了，但它下面不是函数，也是一个装饰器，于是表示：要不哥们，你先装饰。然后执行 @deco2，但它下面还是一个装饰器，于是重复了刚才的话，把皮球踢给 @deco3。

当执行 @deco3 的时候，发现下面终于是一个普通的函数了，于是装饰了。

deco3 装饰完毕之后，foo = deco3(foo)。然后 deco2 发现 deco3 已经装饰完毕，那么会对 deco3 装饰的结果再进行装饰，此时 foo = deco2(deco3(foo))；同理，再经过 deco1 的装饰，最终得到了 foo  =  deco1(deco2(deco3(foo)))。

于是最终输出：

<deco1><deco2><deco3>古明地觉</deco3></deco2></deco1>

所以当有多个装饰器的时候，会从下往上装饰；然后执行的时候，会从上往下执行。

以上就是装饰器相关的内容，可以说非常简单了，甚至有点水文章的嫌疑，因为核心都在上一篇介绍的闭包当中。还是那句话，理解装饰器的关键就在于理解闭包。

阅读原文

跳转微信打开

楔子

在之前的文章中一直反复提到四个字：名字空间。一段代码执行的结果不光取决于代码中的符号，更多的是取决于代码中符号的语义，而这个运行时的语义正是由名字空间决定的。

名字空间是由虚拟机在运行时动态维护的，但有时我们希望将名字空间静态化。换句话说，我们希望有的代码不受名字空间变化带来的影响，始终保持一致的功能该怎么办呢？随便举个例子：

def login(user_name, password, user):
    if not (user_name == "satori" and password == "123"):
        return "用户名密码不正确"
    else:
        return f"欢迎: {user}"
print(login("satori", "123", "古明地觉"))  # 欢迎: 古明地觉
print(login("satori", "123", "古明地恋"))  # 欢迎: 古明地恋

我们注意到每次都需要输入 username 和 password，于是可以通过使用嵌套函数来设置一个基准值。

def deco(user_name, password):
    def login(user):
        if not (user_name == "satori" and password == "123"):
            return "用户名密码不正确"
        else:
            return f"欢迎: {user}"
    return login
login = deco("satori", "123")
print(login("古明地觉"))  # 欢迎: 古明地觉
print(login("古明地恋"))  # 欢迎: 古明地恋

尽管函数 login 里面没有 user_name 和 password 这两个局部变量，但是不妨碍我们使用它，因为外层函数 deco 里面有。

也就是说，函数 login 作为函数 deco 的返回值被返回的时候，有一个名字空间就已经和 login 紧紧地绑定在一起了。执行内层函数 login 的时候，对于自身 local 空间中不存在的变量，会从和自己绑定的 local 空间里面去找，这就是一种将名字空间静态化的方法。这个名字空间和内层函数捆绑之后的结果我们称之为闭包（closure）。

为了描述方便，上面说的是 local 空间，但我们知道，局部变量不是从那里查找的，而是从 localsplus 里面。只是我们可以按照 LEGB 的规则去理解，这一点心理清楚就行。

也就是说：闭包=外部作用域+内层函数。并且在介绍函数的时候提到，PyFunctionObject 是虚拟机专门为字节码指令的传输而准备的大包袱，global 名字空间、默认参数都和字节码指令捆绑在一起，同样的，也包括闭包。

实现闭包的基石

闭包的创建通常是利用嵌套函数来完成的，我们说过局部变量是通过数组静态存储的，而闭包也是如此。这里再来回顾一下 PyCodeObject 里面的几个关键字段：

• co_localsplusnames：包含所有局部变量、cell 变量、free 变量的名称

• co_nlocalsplus：co_localsplusnames 的长度，或者说这些变量的个数之和

• co_varnames：包含所有局部变量的名称

• co_nlocals：局部变量的个数

• co_cellvars：包含所有 cell 变量的名称

• co_ncellvars：cell 变量的个数

• co_freevars：包含所有 free 变量的名称

• co_nfreevars：free 变量的个数

  
  

因此不难得出它们之间的关系：

• co_localsplusnames = co_varnames + co_cellvars + co_freevars

• co_nlocalsplus = co_nlocals + co_ncellvars + co_nfreevars

  
  

那么这些变量的值都存在什么地方呢？没错就是栈帧的 localsplus 字段中。

我们看一段代码：

def foo():
    name = "古明地觉"
    age = 17
    gender = "female"
    def bar():
        nonlocal name
        nonlocal age
        print(gender)
    return bar
print(foo.__code__.co_cellvars)  # ('age', 'gender', 'name')
print(foo().__code__.co_freevars)  # ('age', 'gender', 'name')
print(foo.__code__.co_freevars)  # ()
print(foo().__code__.co_cellvars)  # ()

和闭包相关的两个字段是 co_cellvars 和 co_freevars。co_cellvars 保存了外层作用域中被内层作用域引用的变量的名字，co_freevars 保存了内层作用域中引用的外层作用域的变量的名字。

所以对于外层函数来说，应该使用 co_cellvars，对于内层函数来说，应该使用 co_freevars。当然无论是外层函数还是内层函数都有 co_cellvars 和 co_freevars，这是肯定的，因为都是函数。

只不过外层函数需要使用 co_cellvars 获取，因为它包含的是外层函数中被内层函数引用的变量的名称；内层函数需要使用 co_freevars 获取，它包含的是内层函数中引用的外层函数的变量的名称。

如果使用外层函数 foo 获取 co_freevars 的话，那么得到的结果显然就是个空元组了，除非 foo 也作为某个函数的内层函数，并且内部引用了外层函数的变量。同理内层函数 bar 也是一样的道理，它获取 co_cellvars 得到的也是空元组，因为对于 bar 而言不存在内层函数。

我们再看个例子：

def foo():
    name = "古明地觉"
    age = 17
    def bar():
        nonlocal name
        nonlocal age
        gender = "female"
        def inner():
            nonlocal gender
        return inner
    return bar
print(foo().__code__.co_cellvars)  # ('gender',)
print(foo().__code__.co_freevars)  # ('age', 'name')

对于函数 bar 而言，它是函数 inner 的外层函数，同时也是函数 foo 的内层函数。所以它在获取 co_cellvars 和 co_freevars 属性时，得到的元组都不为空。因为内层函数 inner 引用了函数 bar 里面的变量 gender，同时函数 bar 也作为内层函数引用了函数 foo 里的 name 和 age。

那么问题来了，闭包变量所需要的空间申请在哪个地方呢？没错，显然是 localsplus。

在以前的版本中，这个字段叫 f_localsplus，现在叫 localsplus。

localplus 是一个柔性数组，它被分成了四份，分别用于：局部变量、cell 变量、free 变量、运行时栈。

所以闭包变量同样是以静态的方式实现的。

闭包的实现过程

介绍完实现闭包的基石之后，我们可以开始追踪闭包的具体实现过程了，当然还是要先看一下闭包对应的字节码。

import dis
code_string = """
def some_func():
    name = "satori"
    age = 17
    gender = "female"
    def inner():
        print(name, age)
    return inner
func = some_func()
func()
"""
dis.dis(compile(code_string, "<file>", "exec"))

字节码指令如下，为了阅读方便，我们省略了源代码行号。

  # ********** 模块对应的字节码 **********
  0 RESUME                   0
  # 加载函数 some_func 对应的 PyCodeObject，压入运行时栈
  2 LOAD_CONST               0 (<code object some_func at ...>)
  # 从栈顶弹出 PyCodeObject，构造 PyFunctionObject，并压入运行时栈
  4 MAKE_FUNCTION            0
  # 从栈顶弹出 PyFunctionObject，然后使用变量 some_func 保存
  6 STORE_NAME               0 (some_func)
  8 PUSH_NULL
  # 加载全局变量 some_func
 10 LOAD_NAME                0 (some_func)
  # 调用
 12 CALL                     0
  # 弹出栈顶的返回值，并使用变量 func 保存
 20 STORE_NAME               1 (func)
 22 PUSH_NULL
  # 加载全局变量 func
 24 LOAD_NAME                1 (func)
  # 调用
 26 CALL                     0
  # 从栈顶弹出返回值，丢弃
 34 POP_TOP
  # 隐式地 return None
 36 RETURN_CONST             1 (None)
  # ********** 外层函数 some_func 对应的字节码 **********
Disassembly of <code object some_func at ...>:
  # 创建 cell 对象 PyCellObject，该指令一会儿说
  0 MAKE_CELL                2 (age)
  2 MAKE_CELL                3 (name)
  4 RESUME                   0
  # 加载常量 "satori"
  6 LOAD_CONST               1 ('satori')
  # 注意这里不是 STORE_FAST，而是 STORE_DEREF
  # 它的作用肯定是将符号 "name" 和字符串常量绑定起来
  # STORE_NAME、STORE_FAST、STORE_DEREF 做的事情是一样的
  # 都是将符号和值绑定起来，只是绑定的方式不一样
  # 比如 STORE_NAME 是通过字典完成绑定，STORE_FAST 是通过数组完成绑定
  # 那么 STORE_DEREF 是怎么绑定的呢？稍后分析  
  8 STORE_DEREF              3 (name)
  # 加载常量 17
 10 LOAD_CONST               2 (17)
  # 使用变量 age 保存
 12 STORE_DEREF              2 (age)
  # name 和 age 被内层函数引用了，所以是 STORE_DEREF
  # 但 gender 没有，所以它对应的是 STORE_FAST
 14 LOAD_CONST               3 ('female')
 16 STORE_FAST               0 (gender)
  # 加载 cell 变量，压入运行时栈
 18 LOAD_CLOSURE             2 (age)
 20 LOAD_CLOSURE             3 (name)
  # 弹出 cell 变量，构建元组
 22 BUILD_TUPLE              2
  # 加载函数 inner 对应的 PyCodeObject
 24 LOAD_CONST               4 (<code object inner at ...>)
  # 构造函数
 26 MAKE_FUNCTION            8 (closure)
  # 将函数使用 inner 变量保存
 28 STORE_FAST               1 (inner)
  # return inner
 30 LOAD_FAST                1 (inner)
 32 RETURN_VALUE
 
 # ********** 内层函数 inner 对应的字节码 **********
Disassembly of <code object inner at ...>:
  0 COPY_FREE_VARS           2
  2 RESUME                   0
  # 加载内置变量 print
  4 LOAD_GLOBAL              1 (NULL + print)
  # 显然它和 LOAD_NAME、LOAD_FAST 的关系也是类似的
  # 也是负责加载变量，然后压入运行时栈  
 14 LOAD_DEREF               1 (name)
 16 LOAD_DEREF               0 (age)
  # 调用 print 函数
 18 CALL                     2
  # 从栈顶弹出返回值，丢弃
 26 POP_TOP
 28 RETURN_CONST             0 (None)

字节码的内容并不难，我们来分析一下，这里先分析外层函数 some_func 对应的字节码。

函数 some_func 里面有三个局部变量，但只有 name 和 age 被内层函数引用了，所以开头有两个 MAKE_CELL 指令。参数为符号在符号表中的索引，对应的符号分别为 age 和 name。我们来看一下这个指令是做什么的。

TARGET(MAKE_CELL) {
    #line 1394 "Python/bytecodes.c"
    // 符号在符号表中的索引，和对应的值在 localplus 中的索引是一致的
    // 所以这里会获取变量对应的值，对于当前来说就是 age 和 name 的值
    // 但很明显此时 name 和 age 还没有完成赋值，所以结果为 NULL
    PyObject *initial = GETLOCAL(oparg);
    // 调用 PyCell_New 创建 Cell 对象
    PyObject *cell = PyCell_New(initial);
    if (cell == NULL) {
        goto resume_with_error;
    }
    // 用 Cell 对象替换掉原来的值
    SETLOCAL(oparg, cell);
    #line 1909 "Python/generated_cases.c.h"
    DISPATCH();
}
// Objects/cellobject.c
PyObject *
PyCell_New(PyObject *obj)
{
    PyCellObject *op;
    // 为 PyCellObject 申请内存
    op = (PyCellObject *)PyObject_GC_New(PyCellObject, &PyCell_Type);
    if (op == NULL)
        return NULL;
    // 增加 obj 指向对象的引用计数，并赋值给 op->ob_ref
    op->ob_ref = Py_XNewRef(obj);
    _PyObject_GC_TRACK(op);
    return (PyObject *)op;
}
// Include/cpython/cellobject.h
typedef struct {
    PyObject_HEAD
    PyObject *ob_ref;
} PyCellObject;

所以 MAKE_CELL 指令的作用是创建 PyCellObject，对于当前来说，会创建两个 PyCellObejct，它们的 ob_ref 字段分别为 age 和 name。只不过由于 name 和 age 还尚未完成赋值，所以此时为 NULL。

接下来就是变量赋值，这个显然没什么难度，我们只需要看一下 STORE_DEREF 指令。并且也容易得出结论，如果局部变量被内层函数所引用，那么指令将不再是 LOAD_FAST 和 STORE_FAST，而是 LOAD_DEREF 和 STORE_DEREF。

TARGET(STORE_DEREF) {
    // 由于在 STORE_DEREF 之前调用了 LOAD_CONST
    // 所以这里会获取上一步压入的常量，对于当前来说就是 17 和 "satori"
    PyObject *v = stack_pointer[-1];
    #line 1463 "Python/bytecodes.c"
    // 这里的 oparg 和 MAKE_CELL 的 oparg 的含义是一样的
    // 此时会拿到对应的 PyCellObject *
    PyObject *cell = GETLOCAL(oparg);
    // 获取 PyCellObject 内部的 ob_ref，并减少引用计数
    PyObject *oldobj = PyCell_GET(cell);
    // 将 PyCellObject 内部的 ob_ref 设置成 v
    PyCell_SET(cell, v);
    Py_XDECREF(oldobj);
    #line 1993 "Python/generated_cases.c.h"
    // 栈收缩
    STACK_SHRINK(1);
    DISPATCH();
}

localplus 保存了局部变量的值，而符号在符号表中的索引，和对应的值在 localplus 中的索引是一致的。所以正常情况下，局部变量赋值就是 localsplus[oparg] = v。

但在执行 MAKE_CELL 指令之后，局部变量赋值就变成了 localsplus[oparg]->ob_ref = v，因为此时 localplus 保存的是 PyCellObject 的地址。

因此在两个 STORE_DEREF 执行完之后，localplus 会变成下面这样。

相信你明白 STORE_FAST 和 STORE_DEREF 之间的区别了，如果是 STORE_FAST，那么中间就没有 PyCellObject 这一层，localsplus 保存的 PyObject * 指向的就是具体的对象。

然后是 gender = "female"，它就很简单了，由于符号 "gender" 在符号表中的索引为 0，那么直接让 localplus[0] 指向字符串 "female" 即可。

到此变量 name、age、gender 均已赋值完毕，此时 localsplus 结构如下。

localsplus[0]、localsplus[2]、localsplus[3] 分别对应变量 gender、age、name，可能有人觉得，这个索引好奇怪啊，我们实际测试一下。

def some_func():
    name = "satori"
    age = 17
    gender = "female"
    def inner():
        print(name, age)
    return inner
print(
    some_func.__code__.co_varnames
)  # ('gender', 'inner')

我们看到 some_func 的符号表里面只有 gender 和 inner，因此 localplus[0] 表示变量 gender。至于 localplus[1] 则表示变量 inner，只不过此时它指向的对象还没有创建，所以暂时为 NULL。

那么问题来了，变量 name 和 age 呢？毫无疑问，由于它们被内层函数引用了，所以它们变成了 cell 变量，并且位置是 co->co_nlocals + i。因为在 localsplus 中，cell 变量的位置是在局部变量之后的，这也完全符合我们之前说的 localsplus 的内存布局。

并且我们看到无论是局部变量还是 cell 变量，都是通过数组索引访问的，并且索引在编译时就确定了，以指令参数的形式保存在字节码指令集中。

接下来执行偏移量为 18 和 20 的两条指令，它们都是 LOAD_CLOSURE。

// 加载 PyCellObject *，即 cell 变量，然后压入运行时栈
TARGET(LOAD_CLOSURE) {
    PyObject *value;
    #line 179 "Python/bytecodes.c"
    value = GETLOCAL(oparg);
    if (value == NULL) goto unbound_local_error;
    Py_INCREF(value);
    #line 66 "Python/generated_cases.c.h"
    STACK_GROW(1);
    stack_pointer[-1] = value;
    DISPATCH();
}

LOAD_CLOSURE 执行完毕后，接着执行 BUILD_TUPLE，将 cell 变量从栈中弹出，构建元组。然后继续执行 24 LOAD_CONST，将内层函数 inner 对应的 PyCodeObject 压入运行时栈。

接着执行 26 MAKE_FUNCTION，将栈中元素弹出，分别是 inner 对应的 PyCodeObject 和一个元组，元组里面包含了 inner 使用的外层函数的变量。当然这里的变量已经不再是普通的变量了，而是 cell 变量，它内部的 ob_ref 字段才是我们需要的。

等元素弹出之后，开始构建函数，我们看一下 MAKE_FUNCTION 指令，它的指令参数为 8。

TARGET(MAKE_FUNCTION) {
    PyObject *codeobj = stack_pointer[-1];
    PyObject *closure = (oparg & 0x08) ? stack_pointer[...] : NULL;
    // ...
    // 创建函数对象
    PyFunctionObject *func_obj = (PyFunctionObject *)
        PyFunction_New(codeobj, GLOBALS());
    Py_DECREF(codeobj);
    if (func_obj == NULL) {
        goto error;
    }
    // 由于指令参数为 8，所以 oparg & 0x08 为真
    if (oparg & 0x08) {
        assert(PyTuple_CheckExact(closure));
        func_obj->func_closure = closure;
    }
    if (oparg & 0x04) {
        assert(PyTuple_CheckExact(annotations));
        func_obj->func_annotations = annotations;
    }
    if (oparg & 0x02) {
        assert(PyDict_CheckExact(kwdefaults));
        func_obj->func_kwdefaults = kwdefaults;
    }
    if (oparg & 0x01) {
        assert(PyTuple_CheckExact(defaults));
        func_obj->func_defaults = defaults;
    }
    // ...
    DISPATCH();
}

所以 PyFunctionObject 再一次承担了工具人的角色，创建内层函数 inner 时，会将包含 cell 变量的元组赋值给 func_closure 字段。此时便将内层函数需要使用的变量和内层函数绑定在了一起，而这个绑定的结果我们就称之为闭包。

但是从结构上来看，闭包仍是一个函数，所谓绑定，其实只是修改了它的 func_closure 字段。当函数创建完毕后，localplus 的结构变化如下。

函数即变量，对于函数 some_func 而言，内层函数 inner 也是一个局部变量，由于符号 inner 位于符号表中索引为 1 的位置。因此当函数创建完毕时，会修改 localplus[1]，让它保存函数的地址。不难发现，对于局部变量来说，如何访问内存在编译阶段就确定了。

函数内部的 func_closure 字段指向一个元组，元组里面的每个元素会指向 PyCellObject。

调用闭包

闭包的创建过程我们已经了解了，我们用 Python 代码再解释一下。

def some_func():
    name = "satori"
    age = 17
    gender = "female"
    def inner():
        print(name, age)
    return inner
func = some_func()
# some_func 调用之后会返回内层函数 inner
# 只不过 inner 的 func_closure 字段保存了 cell 变量
# 而 cell 变量指向的 PyCellObject 对外层作用域的局部变量进行了冻结
# 所以我们也会称呼 inner 函数为闭包，但要知道闭包仍然是个函数
print(func.__name__)  # inner
print(func.__class__)  # <class 'function'>
print(
    func.__closure__[0]
)  # <cell at 0x102019390: int object at 0x1000b02f0>
print(
    func.__closure__[1]
)  # <cell at 0x1002126e0: str object at 0x1001f0b70>
print(func.__closure__[0].cell_contents)  # 17
print(func.__closure__[1].cell_contents)  # satori

调用 inner 函数时，外层函数 some_func 已经执行结束，但它的局部变量 name 和 age 仍可被内层函数 inner 访问，背后的原因我们算是彻底明白了。

因为 name 和 age 被内层函数引用了，所以虚拟机将它们封装成了 PyCellObject *，即 cell 变量，而 cell 变量指向的 cell 对象内部的 ob_ref 字段对应原来的变量。当创建内层函数时，将引用的 cell 变量组成元组，保存在内层函数的 func_closure 字段中。

所以当内层函数在访问 name 和 age 时，访问的其实是 PyCellObject 的 ob_ref 字段。至于变量 name 和 age 对应哪一个 PyCellObject，这些在编译阶段便确定了，我们看一下内层函数 inner 的字节码指令。

函数在执行时会创建栈帧，我们上面看到的 localsplus 是外层函数 some_func 对应的栈帧的 localsplus。而内层函数 inner 执行时，也会创建栈帧，然后在栈帧中执行字节码指令。

首先第一个指令是 COPY_FREE_VARS，看一下它的逻辑。

// 将 func_closure 里面的 cell 变量拷贝到 free 区域
TARGET(COPY_FREE_VARS) {
    #line 1470 "Python/bytecodes.c"
    /* Copy closure variables to free variables */
    PyCodeObject *co = frame->f_code;
    assert(PyFunction_Check(frame->f_funcobj));
    // 获取 func_closure，它指向一个元组，里面保存了 PyCellObject *
    PyObject *closure = ((PyFunctionObject *)frame->f_funcobj)->func_closure;
    assert(oparg == co->co_nfreevars);
    // co_nlocalsplus 等于局部变量、cell 变量、free 变量的个数之和
    // 显然 offset 表示 free 变量对应的内存区域
    int offset = co->co_nlocalsplus - oparg;
    // 将 func_closure 里面的 PyCellObject * 拷贝到 free 区域
    for (int i = 0; i < oparg; ++i) {
        PyObject *o = PyTuple_GET_ITEM(closure, i);
        frame->localsplus[offset + i] = Py_NewRef(o);
    }
    #line 2010 "Python/generated_cases.c.h"
    DISPATCH();
}

处理完之后，localplus 的布局如下，注意：此时是内层函数对应的 localplus。

在构建内层函数时，会将 cell 变量打包成一个元组，交给内层函数的 func_closure 字段。然后执行内层函数创建栈帧的时候，再将 func_closure 中的 cell 变量拷贝到 localsplus 的第三段内存中。当然对于内层函数而言，此时它应该叫做 free 变量。

而在调用内层函数 inner 的过程中，当引用外层作用域的符号时，一定是到 localsplus 里面的 free 区域（第三段内存）去获取对应的 PyCellObject *，然后通过内部的 ob_ref 进而获取符号对应的值。至于 name 和 age 分别对应哪一个 PyCellObject，这些都体现在字节码指令参数当中了。

然后我们再来看看 free 变量是如何加载的，它由 LOAD_DEREF 指令完成。

TARGET(LOAD_DEREF) {
    PyObject *value;
    #line 1453 "Python/bytecodes.c"
    // 加载 PyCellObject *
    PyObject *cell = GETLOCAL(oparg);
    // 获取 PyCellObject 对象的 ob_ref 字段的值
    value = PyCell_GET(cell);
    if (value == NULL) {
        format_exc_unbound(tstate, frame->f_code, oparg);
        if (true) goto error;
    }
    Py_INCREF(value);
    #line 1980 "Python/generated_cases.c.h"
    STACK_GROW(1);
    stack_pointer[-1] = value;
    DISPATCH();
}

这里再补充一点，我们说 localplus 是一个连续的数组，只是按照用途被划分成了四个区域：保存局部变量的内存空间、保存 cell 变量的内存空间、保存 free 变量的内存空间、运行时栈。

但对于当前的内层函数 inner 来说，它是没有局部变量和 cell 变量的，所以 localsplus 开始的位置便是 free 区域。

当然不管是局部变量、cell 变量，还是 free 变量，它们都按照顺序保存在 localplus 中，并且在编译阶段便知道它们在 localsplus 中的位置。比如我们将内层函数 inner 的逻辑修改一下。

在 inner 里面创建了三个局部变量，那么它的字节码会变成什么样子呢？这里我们直接看 print 函数执行时的字节码即可。

因为 inner 里面没有函数了，所以它不存在 cell 变量，里面只有局部变量和 free 变量。

所以虽然我们说 localplus 被分成了四份，但是 cell 区域和 free 区域很少会同时存在。对于外层函数 some_func 来说，它没有 free 变量，所以 free 区域长度为 0。而对于内层函数 inner 来说，它没有 cell 变量，所以 cell 区域长度为 0。

只有函数的里面存在内层函数，并且外面存在外层函数，那么它才有可能同时包含 cell 变量和 free 变量。

但为了方便描述，我们仍然认为 localplus 被分成了四个区域，只不过对于外层函数 some_func 而言，它的 free 区域长度为 0；对于 inner 函数而言，它的 cell 区域长度为 0。

当然这些都是概念上的东西，大家理解就好。但不管在概念上 localplus 怎么划分，它本质上就是一个 C 数组，是一段连续的内存，用于存储局部变量、cell 变量、free 变量（这三种变量不一定同时存在），以及作为运行时栈。

最重要的是，这三种变量都是基于数组实现的静态访问，并且怎么访问在编译阶段就已经确定，因为访问数组的索引会作为指令参数存储在字节码指令集中。

• 比如访问变量 a，底层会访问 localplus[0]；

• 比如访问变量 age，底层会访问 localplus[3]->ob_ref；

这便是静态访问。

小结

本篇文章我们就介绍了闭包，比想象中的要更加简单。因为闭包仍是一个函数，只是将外层作用域的局部变量变成了 cell 变量，然后保存在内部的 func_closure 字段中。

然后执行内层函数的时候，再将 func_closure 里的 PyCellObject * 拷贝到 localplus 的 free 区域，此时我们叫它 free 变量。但不管什么变量，虚拟机在编译时便知道应该如何访问指定的内存。

阅读原文

跳转微信打开

楔子

上一篇文章我们说了 Python 函数的底层实现，并且还演示了如何通过函数的类型对象自定义一个函数，以及如何获取函数的参数。虽然这在工作中没有太大意义，但是可以让我们深刻理解函数的行为。

那么接下来看看函数是如何调用的。

PyCFunctionObject

在介绍调用之前，我们需要补充一个知识点。

def foo():
    pass
class A:
    def foo(self):
        pass
print(type(foo))  # <class 'function'>
print(type(A().foo))  # <class 'method'>
print(type(sum))  # <class 'builtin_function_or_method'>
print(type("".join))  # <class 'builtin_function_or_method'>

如果采用 Python 实现，那么函数的类型是 function，方法的类型是 method。而如果采用原生的 C 实现，那么函数和方法的类型都是 builtin_function_or_method。

关于方法，等我们介绍类的时候再说，先来看看函数。

所以函数分为两种：

• Python 实现的函数，在底层由 PyFunctionObject 结构体实例表示，其类型对象 <class 'function'> 在底层由 PyFunction_Type 表示。

• C 实现的函数（还有方法），在底层由 PyCFunctionObject 结构体实例表示，其类型对象 <class 'builtin_function_or_method'> 在底层由 PyCFunction_Type 表示。

  
  

像我们使用 def 关键字定义的就是 Python 实现的函数，而内置函数则是 C 实现的函数，它们在底层对应不同的结构，因为 C 实现的函数可以有更快的执行方式。

函数的调用

我们来调用一个函数，看看它的字节码是怎样的。

import dis 
code_string = """
def foo(a, b):
    return a + b
foo(1, 2)
"""
dis.dis(compile(code_string, "<file>", "exec"))

字节码指令如下：

  0 RESUME                   0
  # 加载 PyCodeObject 对象，压入运行时栈
  2 LOAD_CONST               0 (<code object foo at 0x7f...>)
  # 从栈顶弹出 PyCodeObject 对象，构建函数
  4 MAKE_FUNCTION            0
  # 将符号 foo 和函数对象绑定起来，存储在名字空间中
  6 STORE_NAME               0 (foo)
  8 PUSH_NULL
  # 加载全局变量 foo，压入运行时栈
 10 LOAD_NAME                0 (foo)
  # 加载常量 1，压入运行时栈
 12 LOAD_CONST               1 (1)
  # 加载常量 2，压入运行时栈
 14 LOAD_CONST               2 (2)
  # 弹出 foo 和参数，进行调用
  # 指令参数 2，表示给调用的函数传递了两个参数
  # 函数调用结束后，将返回值压入栈中
 16 CALL                     2
  # 因为没有用变量保存，所以从栈顶弹出返回值并丢弃
 24 POP_TOP
  # 隐式的 return None
 26 RETURN_CONST             3 (None)
  
  # 函数内部逻辑对应的字节码，比较简单，就不说了
Disassembly of <code object foo at 0x7f6...>:
  0 RESUME                   0
  2 LOAD_FAST                0 (a)
  4 LOAD_FAST                1 (b)
  6 BINARY_OP                0 (+)
 10 RETURN_VALUE

我们看到函数调用使用的是 CALL 指令，那么这个指令都做了哪些事情呢？

TARGET(CALL) {
    // ...
    // 运行时栈从栈底到栈顶的元素分别是：NULL, 函数, 参数1, 参数 2, ...
    // 至于为啥会有一个 NULL，我们再看一下刚才的字节码指令就明白了
    // 在 LOAD_NAME 将函数对象的指针压入运行时栈之前，先执行了 PUSH_NULL
    // 所以栈底元素是 NULL，不过问题又来了，为啥要往栈里面压入一个 NULL 呢
    // PUSH_NULL 这个指令我们之前也见过，只不过当时没有解释
    // 它是干嘛的，接下来你就会明白
    // oparg 表示给函数传递的参数的个数，所以 args 指向第一个参数
    PyObject **args = (stack_pointer - oparg);
    // 等价于 *(args - 1)，显然这是函数
    PyObject *callable = stack_pointer[-(1 + oparg)];
    // *(args - 2) 毫无疑问就是栈底元素 NULL
    // 但它却被赋值为 method，难道和方法有关吗？
    PyObject *method = stack_pointer[-(2 + oparg)];
    PyObject *res;  // 返回值
    #line 2653 "Python/bytecodes.c"
    // 如果 method 不为 NULL，说明执行的不是普通的函数，而是方法
    // 所谓方法其实就是将函数和 self 绑定起来的结果
    int is_meth = method != NULL;
    int total_args = oparg;
    // 总之现在我们明白为什么要压入一个 NULL 了，就是为了和方法调用保持统一
    // 如果调用的是方法，那么栈里的元素就是：函数, self, 参数1, 参数2, ...
    // 方法是对函数和 self 的绑定，调用方法本质上还是在调用函数
    // 只不过调用的时候，会自动传递 self，举个例子
    /* 
     * class A:
     *     def foo(self):
     *         pass
     *
     * a = A()
     */
    // 如果是 A.foo，那么拿到的就是普通的函数
    // 因为函数定义在类里面，所以 A.foo 也叫类的成员函数，但它依旧是一个普通的函数
    // 如果是 a.foo，那么拿到的就是方法，它会将 A.foo 和实例对象 a 自身绑定起来
    // 调用方法时会自动传递 self，所以 a.foo() 本质上就是 A.foo(a)
    if (is_meth) {  // 当 is_meth 为真时
        callable = method;  // method 才是要调用的 callable
        args--;  // 此时 self 变成了真正意义上的第一个参数，因此 args--
        total_args++;  // 参数个数加 1，因此 total_args++
    }
    // 通过 PUSH_NULL，可以让函数和方法的调用对应同一个指令
    // 当然，即使不考虑方法，提前 PUSH 一个 NULL 在逻辑上也是正确的
    // 因为任何函数都有返回值，执行完之后要设置在栈顶的位置
    // 而一开始 PUSH 的 NULL 正好为返回值预留了空间
    
    // ...
    // 如果调用的函数，那么栈里的元素是：NULL, 函数, 参数1, 参数2, ...
    // 如果调用的方法，那么栈里的元素是：函数, self, 参数1, 参数2, ...
    // 但对于方法而言，栈里的元素还有一种情况：NULL, 方法, 参数1, 参数2, ...
    // 对于这种情况，要将方法里面的函数和 self 提取出来
    // 所以当 is_meth 为 0，但 callable 的类型是 <class 'method'> 时
    if (!is_meth && Py_TYPE(callable) == &PyMethod_Type) {
        is_meth = 1;  // 将 is_meth 设置为 1
        args--;       // args 依旧向前移动一个位置
        total_args++; // 参数总个数加 1
        // 获取方法里面的实例对象
        PyObject *self = ((PyMethodObject *)callable)->im_self;
        // args 向前移动一个位置之后，它指向了目前方法所在的位置
        // 将该位置的值换成 self
        args[0] = Py_NewRef(self);
        // 获取方法里面的函数
        method = ((PyMethodObject *)callable)->im_func;
        // 将 args 的前一个位置的值设置成函数
        args[-1] = Py_NewRef(method);
        Py_DECREF(callable);
        callable = method;
        // 所以之前栈里的元素是：NULL, 方法, 参数1, 参数2, ...
        // args 之前也指向`参数1`，但在 args-- 之后，便指向了`方法`
        // 等到将 args[0] 设置成 self，将 args[-1] 设置成函数之后
        // 栈里的元素就变成了：函数, self, 参数1, 参数2, ...
    }
    // 到这里为止，不管是调用函数还是调用方法，逻辑都变得统一了
    // 此时变量 callable 指向实际要调用的函数
    // args 指向第一个参数，total_args 表示参数的个数
    int positional_args = total_args - KWNAMES_LEN();
    // 函数在初始化时，它的 vectorcall 字段会被设置为 _PyFunction_Vectorcall
    // 所以对于函数来讲，下面这个条件是成立的，因此可以被内联
    if (Py_TYPE(callable) == &PyFunction_Type &&
        tstate->interp->eval_frame == NULL &&
        ((PyFunctionObject *)callable)->vectorcall == _PyFunction_Vectorcall)
    {
        // 获取 co_flags
        int code_flags = ((PyCodeObject*)PyFunction_GET_CODE(callable))->co_flags;
        // 如果是函数的 PyCodeObject，那么 local 名字空间指定为 NULL
        // 因为局部变量不是从 local 名字空间中加载的，而是静态访问的
        PyObject *locals = code_flags & CO_OPTIMIZED ? NULL : \
                Py_NewRef(PyFunction_GET_GLOBALS(callable));
        // 在当前栈帧之上创建新的栈帧，初始化相关字段
        // 然后推入到虚拟机为其准备的 C Stack 中
        _PyInterpreterFrame *new_frame = _PyEvalFramePushAndInit(
            tstate, (PyFunctionObject *)callable, locals,
            args, positional_args, kwnames
        );
        kwnames = NULL;
        // 将运行时栈清空
        STACK_SHRINK(oparg + 2);
        if (new_frame == NULL) {
            goto error;
        }
        JUMPBY(INLINE_CACHE_ENTRIES_CALL);
        frame->return_offset = 0;
        DISPATCH_INLINED(new_frame);
    }
    // 到这里 callable 不是一个普通的 Python 函数，但它支持 vector 协议
    // 进行调用
    res = PyObject_Vectorcall(
        callable, args,
        positional_args | PY_VECTORCALL_ARGUMENTS_OFFSET,
        kwnames);
    // ...
    kwnames = NULL;
    assert((res != NULL) ^ (_PyErr_Occurred(tstate) != NULL));
    Py_DECREF(callable);
    for (int i = 0; i < total_args; i++) {
        Py_DECREF(args[i]);
    }
    if (res == NULL) { STACK_SHRINK(oparg); goto pop_2_error; }
    #line 3790 "Python/generated_cases.c.h"
    STACK_SHRINK(oparg);
    STACK_SHRINK(1);
    stack_pointer[-1] = res;
    next_instr += 3;
    CHECK_EVAL_BREAKER();
    DISPATCH();
}

当调用函数时，会执行 _PyFunction_Vectorcall，否则执行 PyObject_Vectorcall。

以上就是函数的调用逻辑，然后再补充一点，我们说 PyFrameObject 是根据 PyCodeObject 创建的，而 PyFunctionObject 也是根据 PyCodeObject 创建的，那么 PyFrameObject 和 PyFunctionObject 之间有啥关系呢？

如果把 PyCodeObject 比喻成妹子的话，那么 PyFunctionObject 就是妹子的备胎，PyFrameObject 就是妹子的心上人。其实在栈帧中执行指令的时候，PyFunctionObject 的影响就已经消失了。

也就是说，最终是 PyFrameObject 对象和 PyCodeObject 对象两者如胶似漆，跟 PyFunctionObject 对象之间没有关系，所以 PyFunctionObject 辛苦一场，实际上是为别人做了嫁衣。PyFunctionObject 主要是对 PyCodeObject 和 global 名字空间的一种打包和运输方式。

阅读原文

跳转微信打开