Python 进程启动时，需要初始化解释器、导入模块、创建对象并构建各种缓存。对常驻服务而言，这些工作通常只发生一次；但对命令行工具、Serverless 函数、短生命周期任务和频繁创建的子进程，几十到几百毫秒的初始化都会直接进入用户可见的延迟。
在 Python Language Summit 2026 的相关提案中，Hood Chatham 提出了两个相互配合的方向：为 CPython 引入内存快照，并建立更明确的初始化阶段。核心思路不是单纯让某一次 import 更快，而是把可复用的解释器状态提前准备好，之后从已准备的状态恢复进程。
快照试图省掉哪些工作
一个典型 Python 程序启动时，大致会经历这些步骤：
- 创建并配置解释器运行时；
- 初始化内建模块和导入系统；
- 搜索、读取并执行 Python 模块；
- 创建类、函数、常量和模块级对象；
- 构建正则表达式、路由表、序列化器等应用缓存；
- 读取环境变量、打开连接并进入实际业务逻辑。
其中并非所有状态都适合进入快照。代码对象、不可变配置模板、预先导入的标准库和确定性缓存通常更容易复用；文件描述符、数据库连接、随机数状态、线程、密钥以及与当前机器绑定的资源则需要谨慎处理，甚至必须在恢复后重新创建。
因此，内存快照真正需要解决的不只是“保存一段内存”。CPython 堆中存在对象引用、垃圾回收元数据、扩展模块私有状态和平台相关数据。恢复后的对象必须仍然符合解释器不变量，外部资源也不能因为复制了一个整数形式的句柄就被误认为仍然有效。
可以把理想流程理解为：
创建解释器
↓
执行可重复、无外部副作用的初始化
↓
到达快照边界
↓
保存可恢复状态
↓
多次恢复
↓
执行当前进程专属的初始化并处理任务
这里的“快照边界”正是显式初始化阶段的重要性所在。没有边界，解释器很难判断某个模块级对象是可共享模板，还是只能在当前进程中存在的资源。
为什么需要明确的初始化阶段
Python 项目经常把大量工作放在模块顶层：
# 导入时立即执行
config = load_config()
db = connect_to_database(config.database_url)
model = load_large_model(config.model_path)
这种写法对普通应用很直接，却让导入、配置加载和外部资源创建混在了一起。若在上述代码执行后制作快照，数据库连接可能已经失效，配置可能属于另一套部署环境，模型加载过程还可能依赖 GPU 或本地文件。
更适合快照的结构，是把确定性的准备工作和进程专属初始化分开。下面是一个今天就能采用的应用设计模式；它不是对未来 CPython API 的假设：
# app.py
from dataclasses import dataclass
import re
# 可重复、无外部资源依赖的准备工作
_ROUTE_PATTERN = re.compile(r"^/users/(?P<user_id>[0-9]+)$")
@dataclass(frozen=True)
class Config:
database_url: str
_runtime = None
def initialize(config: Config) -> None:
"""在进程启动或快照恢复后创建进程专属资源。"""
global _runtime
if _runtime is not None:
return
# 示例中用字典代替真实数据库连接，便于直接运行。
_runtime = {
"database_url": config.database_url,
"connected": True,
}
def handle(path: str) -> dict:
if _runtime is None:
raise RuntimeError("call initialize() before handle()")
match = _ROUTE_PATTERN.match(path)
if not match:
return {"status": 404}
return {
"status": 200,
"user_id": int(match.group("user_id")),
"database": _runtime["database_url"],
}
if __name__ == "__main__":
initialize(Config(database_url="sqlite:///app.db"))
print(handle("/users/42"))
运行：
python app.py
这个例子把正则表达式放在可提前准备的区域，把数据库相关状态留在 initialize() 中。即使未来快照机制的具体接口与此不同，这种分层仍然有价值：测试更容易，导入副作用更少，进程恢复后的资源重建点也更清晰。
先测量：启动时间到底花在哪里
在等待底层快照能力成熟之前，可以先测量应用的进程启动和导入成本。下面的脚本不依赖第三方包，会多次启动全新的 Python 子进程，并报告中位数和较高分位耗时。
# benchmark_startup.py
import statistics
import subprocess
import sys
import time
def percentile(values, ratio):
ordered = sorted(values)
index = min(len(ordered) - 1, int(len(ordered) * ratio))
return ordered[index]
def main():
if len(sys.argv) < 2:
raise SystemExit(
'usage: python benchmark_startup.py "import your_package" [runs]'
)
statement = sys.argv[1]
runs = int(sys.argv[2]) if len(sys.argv) > 2 else 30
command = [sys.executable, "-c", statement]
samples_ms = []
for _ in range(runs):
started = time.perf_counter()
subprocess.run(
command,
check=True,
stdout=subprocess.DEVNULL,
stderr=subprocess.DEVNULL,
)
samples_ms.append((time.perf_counter() - started) * 1000)
print(f"command: {command}")
print(f"runs: {runs}")
print(f"median: {statistics.median(samples_ms):.2f} ms")
print(f"p90: {percentile(samples_ms, 0.90):.2f} ms")
print(f"min: {min(samples_ms):.2f} ms")
if __name__ == "__main__":
main()
将 your_package 换成实际入口包：
python benchmark_startup.py "pass" 50
python benchmark_startup.py "import your_package" 50
第一条命令近似测量创建解释器和子进程的基础成本，第二条还包括应用导入成本。两者之差虽然不是严格的实验室级指标，却足以判断优化重点是在解释器启动、模块导入，还是后续初始化。
还可以用 CPython 自带的导入计时功能定位慢模块：
python -X importtime -c "import your_package" 2> import-time.log
查看日志末尾以及累计时间较高的模块，不要只盯着单个模块的自身耗时。一个很快的模块如果触发了庞大的依赖树，同样可能成为启动瓶颈。
快照不会自动消除所有冷启动
内存快照可以减少重复的解释器和对象构建工作，但它不等于完整的应用镜像。实际落地时至少要回答以下问题：
- 可移植性：快照是否绑定 CPython 小版本、操作系统、CPU 架构或编译选项？
- 扩展模块：C 扩展保存的指针和进程外资源能否安全恢复？
- 安全性：环境变量、访问令牌和用户数据是否意外进入快照？
- 随机性：哈希种子、随机数生成器和加密状态是否必须重新初始化？
- 并发状态：线程、锁和异步事件循环在恢复后处于什么状态？
- 部署更新：代码或依赖变化后，旧快照如何检测并失效？
- 资源生命周期：套接字、临时文件和数据库连接由谁在恢复后重建？
此外，快照越大，读取和映射它的成本也越高。如果一个程序只导入少量模块，快照管理成本可能超过节省的时间。真正受益最大的，往往是启动频繁、初始化确定、依赖较多，而且对延迟敏感的工作负载。
现在可以做的准备
团队不必等到 CPython 提供正式机制后才开始行动。可以先做四件事：
- 用独立进程测量真实入口，而不是只测函数调用；
- 清理模块顶层的网络请求、连接创建和环境相关副作用；
- 把初始化划分为“可重复准备”和“当前进程资源创建”；
- 为初始化函数加入幂等性、失败清理和可观测性。
内存快照是否最终带来显著收益，取决于 CPython 的实现边界，也取决于应用是否能明确表达自己的生命周期。对于开发者而言，最值得提前采用的并不是某个尚未确定的接口，而是可测量的启动路径、低副作用的导入过程，以及清晰的初始化边界。