Python 的 import 为什么第二次几乎不要钱？sys.modules 缓存与模块单例的代价

结论先行：import 的「第二次免费」靠的是一张字典——sys.modules。模块一旦加载过，再次 import 只是 230 纳秒的字典查询；但第一次 import 要走过「查找→编译→执行」全链路，实测一个 1500 个函数的模块冷启动 46.8 毫秒，有 pyc 缓存后降到 3.9 毫秒。这篇用 8 组实验讲清缓存机制、模块单例、pyc 到底省了什么，以及循环 import 为什么有时能跑有时崩。

1. 第二次 import 只是一次字典查询

import sys, time
t0 = time.perf_counter()
for _ in range(100000):
    import json
print((time.perf_counter() - t0) / 100000)   # 2.3e-07 秒

。这不是「重新加载了一遍 json」，而是 import 系统第一件事就是查 

 字典，命中就直接返回。import 语句的编译结果里甚至没有文件 IO，只有一个字典查找加名字绑定。

2. sys.modules：整个 import 系统的缓存表

 是一个普通的 dict，键是模块名，值是模块对象。它的行为决定了 import 的三个特点：

 恒为 True——全进程只有一个 json 模块对象，所有 import 者共享同一份状态。这是模块级单例模式的实现基础，也是「修改模块属性会影响所有使用者」的原因。

>>> import decimal, sys
>>> sorted(k for k in sys.modules if k == 'json' or k.startswith('json.'))
['json', 'json.decoder', 'json.encoder', 'json.scanner']
>>> 'json' in sys.modules   # import decimal 之后
True                        # decimal 把 json 也拖进来了

一次 import 触发的是整棵依赖树的加载，树上的每个节点都进 sys.modules。这也是「import 开销」难以预估的原因：你以为 import 了一个小工具，它可能拖进来半个标准库。

3. 打破单例的两种方式，代价完全不同

模块对象进了 sys.modules 就稳如泰山，但有两把刀能动它：

 相同——它把模块代码在原有命名空间里重新跑一遍，所以旧引用无需更新就能看到新定义；而删字典条目再 import，拿到的是另一个对象，旧引用还挂在老对象上，两个副本的状态会分叉。

测试里 mock 模块用后者，线上热更新想都别想。

sys.modules 管的是「进程内」，pyc 管的是「进程间」。第一次 import 一个 1500 个函数的模块（源码 65KB）：

快了 12 倍，但剩下的 3.9 毫秒一分没少

——pyc 只省「源码→字节码」的编译，模块体的执行（定义 1500 个函数、建 1500 个对象）每次 import 都要重跑。这解释了一个常见困惑：明明有 

 的环境（比如多数 Docker 镜像）连 pyc 都不写，每次冷启动全额付费。

5. importtime：把 import 开销摊开看

import time:       3391 |      15806 | decimal
import time:       4063 |       9423 |   _decimal
import time:       4807 |      57830 |     json

读法：第一列是模块自身耗时（μs），第二列是含子模块的累计。decimal 自身只要 3.4 毫秒，但连带 _decimal 和 json，累计 15.8 毫秒。

做启动优化时，先跑 importtime 找累计值最大的那几个

6. 循环 import：为什么有时能跑，有时崩

# cyc_a.py
import cyc_b        # 此时 cyc_b 开始执行
VAL_A = 1
# cyc_b.py
import cyc_a        # cyc_a 已在 sys.modules（部分初始化）→ 拿到半成品
VAL_B = 2

的 cyc_a 模块对象，只要 cyc_b 不在模块顶层立刻访问 

ImportError: cannot import name 'VAL_C' from partially initialized module 'cyc_c'

 形式对循环宽容（拿到半成品也行），

 形式苛刻（必须当场拿到属性）。

 所以循环 import 的救命写法就是统一用 

7. from X import Y 并不比 import X 便宜

from-import 先完整加载整个模块，再从模块对象上取属性绑定到本地名字

，一步都没少。它省不了加载，只在用法上顺手。

一句话收尾：import 的第二春来自 sys.modules 字典查询（230 纳秒），第一春的账单是编译加执行（46.8 毫秒）；pyc 只能缓存前者的一半，模块单例和循环 import 的脾气，都从这张字典的语义里来。

import 第二次几乎不要钱，靠的是 sys.modules 字典：模块加载过，再 import 只是 230 纳秒的字典查询；但首次 import 要走查找→编译→执行全链路，1500 个函数的模块冷启动 46.8 毫秒，有 pyc 缓存降到 3.9 毫秒。8 组实验讲清缓存机制、模块单例、pyc 到底省了什么与循环 import 的两种死法。

人工智能

Python的import机制中，sys.modules字典缓存实现了模块单例，第二次import仅需230纳秒查询；首次加载需经历查找、编译、执行全流程，1500个函数模块冷启动46.8毫秒，有pyc缓存后降至3.9毫秒。reload与删除缓存行为差异大，pyc只省编译不省执行，from-import与import开销相同，循环import需用importx形式规避半初始化问题。

Windows

Docker

Python

JSON

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Python的import机制中，sys.modules字典缓存实现了模块单例，第二次import仅需230纳秒查询；首次加载需经历查找、编译、执行全流程，1500个函数模块冷启动46.8毫秒，有pyc缓存后降至3.9毫秒。reload与删除缓存行为差异大，pyc只省编译不省执行，from-import与import开...

Python 的 import 为什么第二次几乎不要钱？sys.modules 缓存与模块单例的代价

Python 的 import 为什么第二次几乎不要钱？sys.modules 缓存与模块单例的代价

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐