Python 3.15 延迟导入怎样评估启动收益

评估 Python 3.15 延迟导入，不只比较程序打印第一行的速度：应在同一解释器、同一依赖环境下，分别测量不使用该依赖的入口、首次使用依赖的成本，以及完成实际任务的端到端时间。lazy import 推迟加载，未使用的模块可能省去工作；必用模块的成本则可能只是从启动挪到首次使用。

Python 3.15 官方文档入口：https://docs.python.org/3.15/
官方版本说明：https://www.python.org/downloads/release/python-3150/

帮助命令和真正的业务命令不是同一负载

考虑一个支持查看帮助与生成内存归档的命令行工具。帮助入口不需要压缩归档模块，但若在文件开头立即导入相关依赖，每次查看帮助仍可能承担导入工作。显式延迟导入可以保持依赖声明集中，同时把加载留给实际需要它的分支。

这是需要按入口验证的工程判断，不是所有 Python 工具都能获得固定收益。小依赖、已经被其他模块提前导入的依赖，或每个入口都立即用到的依赖，留给启动优化的空间会不同。本文的小例子用于解释测量边界，不模拟大型项目，也不提供实测加速数字。

普通、函数内和显式延迟导入怎么选

函数内导入不是 Python 3.15 新语法，它把普通导入语句放到较晚执行的路径上。lazy 则只能在模块作用域使用，不能把它塞进函数、类体或 try 块；星号导入和 future 导入也不适用。

以下示例的六个实体为命令入口、帮助分支、归档分支、延迟绑定、zipfile 模块与内存归档。帮助分支不使用延迟绑定；归档分支使用它访问 zipfile 模块并构建内存归档。这些依赖关系决定哪些路径有可能省去导入工作。

保留业务行为，只改变一个导入点

把下列内容保存为 cli_lazy.py。它只在内存生成虚构归档，不访问网络或写磁盘：

import io
import sys
import time
lazy import zipfile  # Python3.15：在首次使用名称时加载。

def archive():
    buffer = io.BytesIO()
    started = time.perf_counter()
    # 首次名称使用在计时区间中，包含归档模块加载及本次工作。
    with zipfile.ZipFile(buffer, "w") as package:
        package.writestr("demo.txt", "演示内容")
    elapsed_ms = (time.perf_counter() - started) * 1000
    size = len(buffer.getvalue())
    buffer.close()  # ZipFile已退出上下文，再关闭底层内存缓冲区。
    print(f"归档字节数={size};首次归档区间毫秒={elapsed_ms:.3f}")

def main():
    arguments = sys.argv[1:]
    if arguments == ["--help"]:
        print("用法：--help 或 archive")
        return 0
    if arguments == ["archive"]:
        archive()
        return 0
    print("参数不受支持", file=sys.stderr)
    return 2

if __name__ == "__main__":
    raise SystemExit(main())

再准备 cli_eager.py：其余代码保持相同，仅把 lazy import zipfile 改成 import zipfile。若比较函数内方案，则移除模块级 zipfile 导入，在 archive() 的计时开始之后加入普通 import zipfile，另存为 cli_inline.py。不把业务输出、归档内容或异常策略一起改掉。

代码打印的“首次归档区间”包含模块加载与归档工作，不是纯导入耗时。普通导入版本已经在区间外加载了模块，所以不能仅比较这个区间，就宣称普通导入的完整任务更快。必须另测整个新进程。

新进程测量能避免 sys.modules 的复用误导

连续在同一进程里测量普通 import，后续样本通常已经受到模块缓存影响。下面的 measure_cli.py 每个样本都启动新子进程，分别观察帮助入口和完整归档任务。它测量的是父进程发起启动到子进程退出的墙钟时间，不是应用内部某个函数：

import statistics
import subprocess
import sys
import time

# 使用运行本脚本的同一解释器；三份文件须由读者按上文准备。
scripts = ["cli_eager.py", "cli_inline.py", "cli_lazy.py"]
paths = [["--help"], ["archive"]]
samples = {(script, tuple(path)): [] for script in scripts for path in paths}

for repeat in range(20):
    # 交替方案顺序，降低固定先后顺序带来的缓存偏差。
    ordered = scripts if repeat % 2 == 0 else list(reversed(scripts))
    for script in ordered:
        for path in paths:
            started = time.perf_counter()
            subprocess.run(
                [sys.executable, "-X", "lazy_imports=normal", script, *path],
                check=True, timeout=30,
                stdout=subprocess.DEVNULL,
                stderr=subprocess.PIPE,
            )
            elapsed_ms = (time.perf_counter() - started) * 1000
            samples[(script, tuple(path))].append(elapsed_ms)

for (script, path), values in samples.items():
    # 输出真实样本统计；不把一次最小值当成稳定收益。
    print(script, path, "样本数", len(values),
          "中位毫秒", round(statistics.median(values), 3),
          "最大毫秒", round(max(values), 3))

用同一 Python 3.15 环境运行测量脚本，固定机器负载、依赖版本和字节码缓存状态。20 次是教学样本数量，不是统计充分性的保证；真实比较应按噪声程度增加样本，并记录原始数据。新进程并不等于冷文件系统缓存，不要给这个结果贴上“冷盘启动”的标签。

check=True 和超时会让失败样本中止脚本，而不是把失败退出当作“快”。捕获的标准错误应在读者诊断失败时查看，避免把敏感路径原样上传。本文没有执行这些代码，因而没有可报告的测量结果。

导入追踪找候选，最终时间还要单独测

可在自己的项目中使用导入耗时追踪比较两条路径：

# 供读者执行：累计耗时包含嵌套导入，不能逐行直接相加。
python3.15 -X lazy_imports=normal -X importtime cli_lazy.py --help
python3.15 -X lazy_imports=normal -X importtime cli_lazy.py archive

追踪的输出与计时开销会干扰基准，所以先用它找被导入的依赖，再关闭追踪测端到端样本。带有 self 与累计时间的导入记录也不能机械求和。

评估的六个对象是帮助完成时间、完整任务时间、首次使用区间、导入追踪、错误时机与初始化副作用。前两个是入口指标，中间两个是诊断证据，后两个是语义成本。导入追踪帮助解释时间差；错误时机和初始化副作用决定能否接受这份收益。

哪些依赖不适合直接改成延迟导入

依赖导入时会登记插件、配置日志或修改注册表，而后续代码仅读取注册结果、不直接使用导入名称时，延迟导入可能让原来的初始化没有发生。启动检查希望尽早发现缺失依赖时，也不应只为更快打印帮助而推迟必需依赖的错误。

长驻服务要另外评估首次业务请求；可以把必要的依赖初始化放在接流量前的明确准备阶段，但应测量准备成本，而不是称其“消失”。延迟导入并非后台加载线程，也不意味着模块初始化可以跳过。

支持旧版 Python 时，在版本判断分支中写 lazy import 仍可能被旧解析器拒绝。函数内普通导入是一个兼容选择；当前语言文档也提供模块级 __lazy_modules__ 作为选择性兼容机制，但两种运行时的错误与副作用时机仍不同。首轮评估不建议把全局模式改为 all，否则改动范围扩大，难以区分单个导入点的影响。

语言语法说明：https://docs.python.org/3.15/reference/simple_stmts.html
命令行与追踪说明：https://docs.python.org/3.15/using/cmdline.html
PEP 810：https://peps.python.org/pep-0810/

两个相关问题

把所有 import 改成 lazy 就能保证启动更快吗？不能。其他导入可能提前加载同一模块，初始化依赖也可能不适合推迟，收益取决于实际路径。

帮助命令成功，代表业务依赖齐全吗？不代表。没有访问延迟名称时，加载错误可能尚未发生。依赖可用性与帮助入口性能应分开判断。

选择延迟导入的依据，是不用的路径少做工作，同时使用的路径仍满足延迟与可预测性要求。启动中位数、完整任务耗时和错误行为一起比较，才是一份能支撑迁移的结论。