首次 import 花 2048 微秒，第二次只要 1.1 微秒——差了约 1800 倍

 这个全局缓存。所以"函数里写 import 会不会很慢"这类担心基本是多余的：实测函数内重复 import 10 万次，每次只要 193 纳秒。本文用实机数据把 import 的完整流程拆一遍，顺带讲清 

import sys, time
del sys.modules['json']          # 强制清掉缓存
t0 = time.perf_counter_ns(); import json; t1 = time.perf_counter_ns()
print((t1-t0)/1000, 'us')        # 2048.6 us ≈ 2 毫秒
t0 = time.perf_counter_ns(); import json; t1 = time.perf_counter_ns()
print(t1-t0, 'ns')               # 1100 ns ≈ 1.1 微秒

实测（CPython 3.13.14）：首次 import json 花 

。首次的钱花在哪？找文件、读源码、编译成字节码、执行模块顶层代码、注册缓存——一整套流程；第二次只干一件事：去 

2. sys.modules：import 的第一站，也是唯一的缓存

 是一个普通字典，key 是模块名，value 是模块对象。解释器启动后这里已经躺了一百多个模块：

import sys
print(len(sys.modules))   # 我这台机器上是 107
print('json' in sys.modules)  # import 之后 True

。查到了就直接返回引用，后面的事全省了。这就是为什么第二次 import 只要 1 微秒——一次字典查找的成本。理解这一点，就理解了 import 性能的 90%。

3. 首次 import 的完整流水线（查不到缓存才走这里）

缓存 miss 之后，CPython 按顺序做这几件事：

 里的 finder（内置模块、冻结模块、路径查找器），路径查找器再按 

：源码编译成字节码（这步最贵，毫秒级）；

：新建模块对象，执行模块顶层代码（顶层语句只在这一步跑一次）；

，之后的 import 全部命中缓存。

拿一个真实模块实测（200 个函数定义的 .py，本测试环境关闭了字节码缓存，正好暴露纯编译成本）：

# 首次：读源码 + 编译 + 执行 → 6153.2µs
# 清掉 sys.modules 后再 import：3288.0µs（没有 .pyc 可省，只能重编译）

默认环境下第二次磁盘级 import 会读 

 没写出来，所以两次都得重新编译——这组"反常"数据反而把 .pyc 缓存的价值衬托得很清楚：有它，省的是毫秒级的编译；没它，每次启动都要付一遍。

4. 函数里写 import 到底贵不贵？193 纳秒

很多人说"import 要写在文件顶部，函数里写会慢"。实测一下：

def f():
    import json
    return json
import timeit
print(timeit.timeit("f()", globals={'f': f}, number=100000))  # 0.019s

函数内 import 10 万次，总共 19ms，每次 193 纳秒。

 里，函数内的 import 就是一次字典查找加一次局部变量绑定。真正要注意的不是性能，而是另外两件事：

（顶层代码只在首次执行一次，靠函数内 import 延迟触发是常见技巧）。

5. 循环导入：唯一会把 import 玩坏的场景

# a.py
import b
X = 'a'
# b.py
import a   # a 还没执行完，sys.modules 里的 a 是"半成品"
print(a.X) # AttributeError

原理用本文的机制一句话说清：

；执行到一半 b 又去 import a，此时缓存里虽有 a，但它的顶层代码还没跑完，

 还不存在——拿到的是一个"半成品"模块。解法就三条：把 import 下沉到函数里（利用 193ns 的廉价缓存查找）、抽公共模块、或者改用 

（推迟到用的时候才取属性）。

：import 的性能账，本质是"一次完整流水线 + 之后全是字典查找"。

函数内 import 不可怕，循环导入才是真要命的那个。

你项目里写过函数内的 import 吗？是 deliberate 的延迟加载，还是被循环导入逼的？评论区聊聊。

结论先行：同一个模块，首次 import 花 2048 微秒，第二次只要 1.1 微秒——差了约 1800 倍。中间隔着的不是魔法，是 sys.modules 这个全局缓存。所以"函数里写 import 会不会很慢"这类担心基本是多余的：实测函数内重复 import 10 万次，每次只要 193 纳秒。本文用实机数据把 import 的完整流程拆一遍，顺带讲清 __pycache__ 和循环导入这两个高频坑。

Python 的 import 到底做了什么？首次 2 毫秒与缓存 1 微秒，中间隔着一个 sys.modules

同一个模块首次 import 花 2048 微秒、第二次只要 1.1 微秒，差约 1800 倍——中间隔着 sys.modules 全局缓存。函数内重复 import 实测每次 193 纳秒。本文拆开 import 完整流程，讲清 __pycache__ 与循环导入两个高频坑。

人工智能

Python import性能实测：首次需2048微秒，缓存命中后仅需1.1微秒，相差1800倍。核心机制是sys.modules全局字典缓存，函数内重复import 10万次每次仅193纳秒。本文拆解首次import完整流程，详解__pycache__字节码缓存价值及循环导入风险，提供可复现数据与解决方案。

解释器

Windows

JSON

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

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

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

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

Python 的 import 到底做了什么？首次 2 毫秒与缓存 1 微秒，中间隔着一个 sys.modules

Python 的 import 到底做了什么？首次 2 毫秒与缓存 1 微秒，中间隔着一个 sys.modules

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐