写这篇文章之前我先把话说在前面不管你是刚学 Python 的入门选手还是已经在生产环境里摸爬滚打了几年的老开发大概率都遇到过类似的场景——一段业务逻辑明明算不了几步但程序启动要等好几秒写了个命令行小工具按下回车之后光标转了半天才出现提示跑单元测试时光是你自己的测试用例还没执行pytest 已经在那里“加载模块”加载到让你怀疑电脑是不是坏了。我过去一直以为这是 Python 解释器本身慢于是去优化算法、换数据结构、上多线程多进程折腾一圈下来收效甚微。直到我拿 cProfile 和 py-spy 对项目做了几次真实的性能采样才猛然反应过来真正拖后腿的很大概率不是你的代码而是模块导入阶段——也就是那一大堆import语句背后的importlib机制。这个话题值得认真写一写因为很多人对import的理解还停留在“把别的文件拿进来用”这层表面根本不清楚 Python 在解析一个import语句时到底做了多少事也不清楚importlib这个标准库能带来怎样的优化空间。这篇文章不搞象牙塔里的理论背诵。我会从 import 的底层语义拆起把常见的性能坑一个个摆出来再给你一组可以直接抄走的importlib高阶优化方案最后用真实场景演示优化前后的差异。适合想深入了解 Python 模块机制、正在做启动性能优化、或者被循环导入折磨过的同学。1. import 的真实成本Python 解释器到底在忙什么很多人把import想得很简单就是把模块文件读取进来。但如果你带着“读取文件”的预期去剖析性能你会漏掉大量开销。实际上一条import语句在 CPython 内部要经过模块定位、编译、构造模块对象、绑定名字这么几步每一步都有实打实的成本。1.1 一次 import 的完整执行链路依次拆开来看import x在解释器层面大致做了这些工作先查sys.modules这个字典。这是一个全解释器共享的模块缓存key 是模块名value 是已经加载好的 module 对象。如果命中直接返回很快但注意“命中只是不重新加载”属性绑定还是会发生。没命中就进入查找流程。依次遍历sys.meta_path上的 finder最常见的是BuiltinImporter、FrozenImporter和PathFinder。PathFinder会扫描sys.path里的每个目录尝试找到与模块名匹配的文件这里实际做的是文件系统 IO。拿到模块的定位信息之后如果文件是.py源码就得走编译流程。Python 会把源码 parse 成 AST再编译成字节码。多数情况下.pyc缓存能命中在__pycache__目录下省掉编译开销但如果源码文件的时间戳或大小发生变化缓存就失效了得重新编译。编译完成后解释器会创建一个空的 module 对象把模块的代码放进去执行。这一步是最耗时的——因为模块里所有顶层的赋值、函数定义、类定义、以及它自己那堆import全部会原地执行一遍。最后才是把那x绑定到你的局部或全局命名空间里。所以一个import语句的成本不是“读一个文件”的成本而是“递归导入这棵依赖树”的成本。你 import 一个 pandas看似只引进一个名字实际可能把 numpy、dateutil、pytz 等上百个模块全部加载进来。某些重型库导入后的常驻内存轻松破数百 MB启动时间是秒级。1.2 importlib 在整个机制里的真实身份标准库里的importlib模块本质上是 import 机制的参考实现和扩展接口。通俗点说解释器内置的import语句底层就是调用importlib的__import__函数而importlib里又暴露了find_spec、module_from_spec、exec_module这类接口让我们能主动干涉导入过程。这给了我们两重好处。第一重是“看懂”你能通过它的接口去检查模块状态、找到模块对应的 spec、甚至手动加载一个模块从而完全理解 import 的每一步。第二重是“改造”你可以介入查找阶段finder、加载阶段loader、甚至模块属性访问阶段__getattr__把导入行为改成按需加载、延迟加载、动态映射这才是性能优化的核心武器。新手最容易犯的错是以为importlib是个“额外的库”跟import是两条路线。实际上后者依赖前者你用importlib.import_module(foo)动态导入效果跟写import foo完全一致只是前者把模块名当成了字符串参数可以在运行时拼接和选择。理解了这层关系你就能明白为什么importlib不只是一个“动态导入工具”更是一个性能调优入口。2. 五个最容易踩的 import 性能坑我见过太多团队在优化 Python 服务时盯着业务代码一通改最后发现启动时间没降多少。实际上他们栽在了一些”看起来没问题“的常规写法上。下面这五个坑基本覆盖了 90% 的 import 性能问题场景。2.1 坑一链式膨胀——import 一个包拖出一片森林模块 A import 模块 B模块 B 又 import 模块 C这是正常的依赖结构但真正可怕的是顶层的__init__.py把整个包的内存全部塞进导入链。典型的例子就是某些科学计算库的老版本包目录下的__init__.py会一次性把子模块全部 import 进来导致你做import pkg时就启动了整个生态。你得知道__init__.py只要被加载它里面所有 import 语句都会递归执行。如果你的包结构是__init__.py里from .a import xxx、from .b import yyy那么在import 你的包的那一刻a 和 b 全部被拉起来了。规避思路很简单顶层文件只暴露最核心的 API子模块按需导入或者用延迟加载后面会专门讲。很多人以为代码写进__init__.py“只是集中导出”却忽略了它有执行成本这个事实。2.2 坑二import 时执行顶层代码而不是只做定义Python 和很多编程语言的一个重大差异是模块导入时顶层代码真的会执行。所以你在模块顶层写# config.py config load_config_from_file(/etc/myapp/config.json) cache init_cache_connection()那么任何地方import config都会立刻触发磁盘读取、网络连接、缓存初始化。哪怕你只是想在别的模块里引用一个常量这些副作用也在劫难逃。合理的做法是懒加载、缓存、或者把副作用封装成显式函数调用。对于分析 import 性能来说这一条尤其值得注意——你可以拿importlib的接口去查每个模块的加载顺序但真正解决性能问题很多时候得先把模块里的“模块级执行逻辑”挪走。2.3 坑三在函数内部的热路径里反复 import我遇到过一种写法def process_data(df): import pandas as pd ...把 import 写进函数里本意是“只有用到的时候才加载”。这比放在顶部已经好很多至少冷启动不会白付钱。但如果这个函数在一个热循环里被调用事情就变了每次调用函数解释器都会走一遍 import 的语义流程。虽然模块对象在sys.modules里能命中不会重复执行模块内部代码但“查找模块对象 绑定属性到局部作用域”的开销仍然存在。高频调用下的累积成本非常可观。正确的做法是如果你的模块生命周期短放函数内部合理但一定要用“模块级局部变量缓存 判断”的模式先把pandas绑定到局部引用或者用functools.lru_cache包一层工厂函数。2.4 坑四把所有 import 放在顶部——默认风格不一定是最优Python 官方风格指南 PEP 8 确实建议把 import 放在模块顶部这是为了风格统一和可读性不是从性能角度做的强制约束。但如果你追求启动性能顶部导入意味着“模块被加载时整棵依赖树会被同步拉起来”。对于 Web 服务、CLI 工具这种启动进程的场景顶部导入把代价集中在了启动阶段。我不建议你为了性能把风格搞得面目全非。但如果你面对的场景是程序启动时间直接影响用户体验比如命令行工具、无服务函数冷启动你就应该主动打破默认风格把重型依赖的导入往调用路径上后移。2.5 坑五循环导入导致的隐式重复加载循环导入带来的不仅仅是ImportError报错它还会让模块加载顺序变得混乱某些模块在“半初始化”状态就被其他模块引用触发各种匪夷所思的运行时错误。更隐蔽的是为了绕开循环导入有人会在模块内部偷偷加上局部 import 或动态 import结果导致同一个模块在多个模块里用不同方式加载引入不必要的性能损耗和难以排查的诡异行为。循环导入的根治方案是重构依赖结构但短期内用延迟导入可以缓解——这个我们下一章展开。3. importlib 高阶优化方案从“延迟”到“主动接管”理解了坑下一步就是动手优化。这一部分是我个人实战里最常用的招式代码可直接抄风险点也都会点出来。3.1 方案一延迟导入的三种常见写法延迟导入不是新概念但很多人只会写“把 import 放进函数里”。下面三种方式按边界不同分别适用第一种函数级延迟def load_image(path): from PIL import Image return Image.open(path)这是最朴素、最安全的方式。PILPillow这个库的导入成本较高如果你只在处理图片时才需要它放在函数里就没白付启动成本。缺点是每次调用都要重新走 import 绑定流程——不过函数调用次数不多的话这点开销可以忽略。第二种模块级缓存延迟_img_module None def load_image(path): global _img_module if _img_module is None: import PIL.Image as _img_module return _img_module.open(path)把 import 的结果缓存到模块级变量。注意这里有个细微但很重要的点import PIL.Image as _img_module会先把PIL.Image赋值给局部变量再赋给全局变量。实际上如果你直接import PIL.Image然后PIL.Image.open()每次也得查属性链。缓存到全局后后续调用只做一次 None 判断效率极高。实测下来在热循环里能省掉不少属性查找时间。第三种使用importlib.util.LazyLoader实现真正的懒加载模块import importlib.util, importlib spec importlib.util.find_spec(big_lib) module importlib.util.module_from_spec(spec, loaderimportlib.util.LazyLoader(spec.loader)) importlib.util.spec_from_loader(big_lib, importlib.util.LazyLoader(spec.loader))这个写法略绕但效果非常彻底LazyLoader会创建一个代理模块对象模块内部代码不会立即执行。当你真正访问模块的属性时它才会把模块加载进来。缺点是会带来属性访问时的额外开销而且某些依赖模块级变量互相引用的场景下容易踩雷非必要不建议在生产环境中大规模铺开。3.2 方案二包级延迟导出——用模块getattr实现轻量占位PEP 562 给模块增加了一个特性可以定义模块级的__getattr__。这意味着你可以在__init__.py里做一个“占位符模块”只有当用户访问某个属性时才真正去加载对应的子模块。# package/__init__.py def __getattr__(name): if name heavy_api: from . import heavy_api return heavy_api raise AttributeError(fmodule {__name__!r} has no attribute {name!r})这么写有个很直观的好处from package import something_light不会触发heavy_api的加载只有from package import heavy_api时Python 访问不到属性会回调__getattr__此时才真正加载子模块。这里最需要注意的坑是不要在__getattr__里做递归的 import 或访问当前模块的其他属性否则容易陷入无限递归。我之前踩过一次延迟加载的函数内部想读取__name__结果触发__getattr__导致无限循环栈直接炸了。所以延迟加载的代码里尽量只访问明确的模块对象不要访问当前模块的未知属性。3.3 方案三用 importlib.find_spec 做模块体检如果你想知道某个模块到底会拖出多少依赖、每个模块加载耗时多少与其猜不如直接写脚本体检。import importlib.util, importlib def inspect_module(module_name): spec importlib.util.find_spec(module_name) if spec is None: print(f{module_name} not found) return loader spec.loader print(fmodule: {module_name}) print(forigin: {spec.origin}) print(floader: {loader}) print(fsubmodule_search_locations: {spec.submodule_search_locations})把这段脚本跑一遍你能直接看到模块对应的文件路径和 loader 类型。再配合sys.modules快照和time.perf_counter()就能精确统计每个 import 的耗时。这才是真正定位性能瓶颈的起点而不是靠猜。3.4 方案四自定义 Loader 和 Finder——主动接管模块解析如果说前面几种方案都是在“节省时间”那么自定义 Loader 和 Finder 就是在“改变模块加载的语义”。一个常见场景项目里有几百个配置文件每个配置对应一个 Python 模块模块内容是一大段配置字典。传统做法是写几百个.py文件然后在代码里挨个import——既慢又难维护。更高阶的做法是写一个自定义 Loader把 JSON 文件映射成模块对象import importlib.util import importlib.abc import json class JsonLoader(importlib.abc.Loader): def __init__(self, filename): self.filename filename def create_module(self, spec): return None def exec_module(self, module): with open(self.filename, r, encodingutf-8) as f: module.data json.load(f)然后在你需要的地方手动加载spec importlib.util.spec_from_file_location(config, /path/to/config.json, loaderJsonLoader(/path/to/config.json)) module importlib.util.module_from_spec(spec) spec.loader.exec_module(module) print(module.data)这算是把 import 玩出了自定义格式加载的味道。同样的思想可以用在加载远程配置、数据库配置、协议响应等场景里。通过实现importlib.abc.Loader的create_module和exec_module你不费吹灰之力就能让 Python 以标准导入语法去消费非.py数据源。再进一步如果你想在import foo时拦截寻找过程实现importlib.abc.MetaPathFinder并把自己注册进sys.meta_path即可。比如把某个模块名统一映射到一个内存中的字符串或者从一个压缩包中动态加载模块。这个方案灵活度极高但同样要小心finder 执行顺序会影响结果你在sys.meta_path最前面注册的 finder 会最先被问到如果它返回了 spec后面的 finder 就不再有执行机会。所以自定义 finder 里的匹配逻辑要足够严格避免误拦截正常的库导入。3.5 方案五预生成字节码缓存与 sys.meta_path 的配合Python 每次 import 模块时都会解析源码。虽然.pyc字节码缓存能减少重复编译但首次编译依然耗时。在部署脚本中预编译所有模块是启动优化的常规操作。你可以用标准库的compileall完成全项目预编译python -m compileall -q /path/to/project执行之后__pycache__目录里会生成所有.py文件对应的.pyc后续导入如果源码没变会直接命中缓存。这套操作对容器镜像构建尤其有效在构建镜像时预编译一次运行时省掉编译开销。但注意预编译不是在所有场景都稳赚。如果你的代码里做了大量动态生成源码再 import 的操作比如 Jinja2 模板转.py后导入compileall并不会帮到这些动态文件。另外如果你手动改了sys.meta_path拦截了模块查找compileall生成的.pyc可能根本不会命中因为它走的是标准 PathFinder 流程。3.6 方案六sys.modules 预注入——用空间换时间前面说过import 的查找阶段会扫描sys.path。如果你的模块搜索路径上有大量目录比如虚拟环境 项目自身路径 各种第三方套件查找本身会产生大量系统调用。某些极端场景下查找到底要遍历多少目录、做多少次 stat是肉眼不可见的隐性成本。这时候可以粗暴一点手动把已知的模块对象直接注入sys.modules。import sys import my_fast_module sys.modules[my_fast_module] my_fast_module之后任何地方import my_fast_module都会直接命中sys.modules缓存跳过 finder 查找流程。这个方案属于空间换时间适合启动阶段已经明确会立即用到的模块。风险是所有地方拿到的都是同一个对象引用如果你在测试用例里想让模块重新加载得先手动从sys.modules里弹掉它。4. 实操案例三个真实场景的 import 优化前后对比理论说得再多不如上手跑一遍。我挑三个我用过的典型场景把优化思路和数据放出来你可以对照自己的项目做迁移。4.1 案例一数据探索脚本torch 与 transformers 的加载痛有一次我写数据处理脚本主要用 pandas 清洗数据、用 sklearn 跑个模型、用 torch 做个简单张量运算。脚本启动时光 import 就花了大概 4 秒。用 py-spy 一看import 阶段占总耗时的 80% 以上。优化思路是拆分用途把 torch 和 transformers 的导入从顶部挪到对应处理函数里同时为 pandas 的子模块做按需导入。# 优化前 import pandas as pd import torch import transformers def load_data(path): return pd.read_csv(path) def preprocess(df): return df[df[col] 0] def model_predict(texts): from transformers import pipeline return pipeline(sentiment-analysis)(texts)# 优化后 def load_data(path): import pandas as pd return pd.read_csv(path) def preprocess(df): import pandas as pd return df[df[col] 0] def model_predict(texts): from transformers import pipeline return pipeline(sentiment-analysis)(texts)你可能觉得奇怪load_data和preprocess都 import pandas那 pandas 不是照样要加载但这里的关键是pandas 不再随着模块顶部导入而被立刻加载而是延迟到第一次真正调用数据处理函数时。对于“读个小文件、发个请求出去”的场景你根本不会触达那部分代码pandas 也就不需要加载。把重型依赖从模块导入路径上摘除之后脚本冷启动从 4.2 秒降到了 0.7 秒左右。这里有个很实用的技巧如果函数内部反复用到同一个模块可以用模块级缓存延迟避免重复绑定开销。比如_pd None def _get_pd(): global _pd if _pd is None: import pandas as pd _pd pd return _pd4.2 案例二CLI 工具启动加速argparse 前面的黑洞CLI 工具是启动延迟最敏感的场域。用户输入命令期待立即反馈你却在导入 pandas 花了几百毫秒体验极差。优化 CLI 的核心原则是argparse 路由分派只做轻量工作重型依赖全部延迟到具体子命令执行时。# 优化前 import click import pandas as pd def analyze(path): df pd.read_csv(path) print(df.describe()) if __name__ __main__: analyze(data.csv)# 优化后 import click def analyze(path): import pandas as pd df pd.read_csv(path) print(df.describe()) if __name__ __main__: analyze(data.csv)看着只是移动了两行实际效果是命令行解析阶段零 pandas 代价。我实测过一个数据对比工具优化前启动耗时 1.8 秒优化后 0.25 秒用户感知完全两个档次。如果你的 CLI 工具命令特别多还可以按子命令做分组延迟导入。比如先解析第一层命令只 import 那个命令对应的功能模块其他全部不加载。4.3 案例三插件系统中用常量映射替代动态 import插件架构里经常要“按名称加载插件”。新手最容易写成这样def load_plugin(plugin_name): module importlib.import_module(fplugins.{plugin_name}.main) return module.get_plugin()动态导入本身没问题但每次手动import_module都要走一遍查找流程。如果插件系统在同一个进程内频繁加载同一个插件你会白白做大量重复查找。优化方案是显式维护一个插件注册表加载过一次就缓存引用import importlib _plugin_cache {} def load_plugin(plugin_name): if plugin_name not in _plugin_cache: module importlib.import_module(fplugins.{plugin_name}.main) _plugin_cache[plugin_name] module return _plugin_cache[plugin_name].get_plugin()更进一步如果你对插件的发现阶段也有性能要求可以在启动时只扫描插件目录并记录地址真正使用时才 import。还可以结合前面的自定义 Finder把插件的“查询”——“定位”——“加载”解耦真正做到按需索引。5. 常见问题与排查技巧实录这块内容是我踩坑最多的地方。import 优化本身不难难的是它引出来的一堆副作用。我把高频问题和排查思路记录下来方便你快速复用。5.1 问题一ImportError: cannot import name我见过大量的cannot import name xxx from yyy。这类错误在优化导入顺序后特别容易冒出来因为延迟导入把加载顺序打乱了。排查思路如下确认你 import 的属性和函数在模块里真实存在且拼写完全一致。不要相信 IDE 的提示直接打开原模块 grep 一下。确认模块之间是否存在循环依赖。如果 A 和 B 互相引用可能会出现“ B 还没有定义完 A 就去拿属性”的半成品状态。检查是否为子模块导出的名字。有时from pkg import xxx依赖的是pkg.__init__.py转导出的属性转导出链条一旦被延迟加载打断就会报错。碰到这类错误最直接的复现方法是单独写一个干净脚本按顺序手动 import 一遍看在哪一步中断然后调整加载顺序或改造成无环依赖结构。5.2 问题二ImportError: attempted relative import with no known parent package这个报错常出现在你把脚本当成主模块运行时。比如你在package/目录下有个mod.py里面写了from . import something然后你直接运行python package/mod.py。这时 Python 不知道mod.py属于哪个包相对导入自然失效。我在优化 import 时也踩过这个坑原因是为了测试一个延迟加载函数把模块当脚本直接运行。解决方案有三种用python -m package.mod运行明确告知 Python 这是包的一部分。在代码里禁用相对导入改成绝对导入。对临时测试脚本直接复制逻辑到独立文件里避免理解成本。5.3 问题三自定义 finder 生效但没有命中实现自己的 MetaPathFinder 之后发现import根本没有走自己的逻辑往往是因为你注册得太晚或者匹配逻辑太严格。sys.meta_path里的 finder 是按顺序遍历的。默认的三驾马车BuiltinImporter、FrozenImporter、PathFinder排在前面你的 finder 如果加在末尾只有前面全部返回 None 才有机会执行。另外如果你的 finder 只认模块名但实际导入时带上了包前缀如import a.b.c那 finder 会先被问a然后a.b最后a.b.c你得能正确处理每一层的查找。调试技巧在 finder 的find_spec方法里临时加上打印确认每次调用时的参数是啥。再看它返回的 spec 的 loader 是不是你预期的类型。大多数“不生效”问题本质是“压根没被调用”或“返回了错误 spec”。5.4 问题四修改代码后 import 还走旧逻辑这是字节码缓存引发的坑。你改了.py文件但sys.modules里还留着旧模块对象或者__pycache__里的.pyc与新源码时间戳不匹配导致 import 结果一直不对。我见过的场景是在一个长驻进程里通过importlib.reload(module)想热更新模块逻辑却发现模块内部的某些引用还指向旧对象。因为reload只重新执行模块代码不会更新已绑定到其他模块里的旧引用。排查方法很简单彻底退出进程重新启动确认问题是否还在。清理__pycache__目录确认是否为陈旧缓存。如果是模块内部状态的问题考虑用进程重启规避别逞强做热更新。5.5 问题五import 之后发现模块里的全局状态被污染这个现象在“延迟导入”后特别常见。模块顶层代码不再立刻执行但当它第一次被真正导入时全局状态突然生效可能会影响其他已经运行的代码逻辑。比如你有一个配置管理模块顶层读取环境变量设置全局连接参数。如果你把它延迟到某个函数里才 import那么在这个函数运行之前其他代码读到的配置可能是不完整的。这种“隐式初始化”问题非常难查排查时只能用二分法先去掉全部延迟导入看问题是否消失再逐个恢复定位到具体模块。我建议你在设计阶段就给模块定义一个显式的init()初始化函数把副作用集中管理而不是依赖模块顶层的执行顺序。这样既保留延迟导入的性能收益又能避免全局状态混乱。5.6 问题六用了 LazyLoader 后模块属性访问变慢LazyLoader本质上是一个代理它在模块真正加载前的每次属性访问都会先做一次状态检查。如果你有个模块被高频访问几千次属性性能损耗反而比不延迟更明显。我有个例子某个配置模块被几百个业务函数读取打开 LazyLoader 之后启动时间确实降低了但运行时的总访问耗时不降反升。这时候最好的方案是换个思路启动时先加载配置模块然后在业务代码里用局部变量绑定参数而不是反复访问模块属性。5.7 常见问题速查表症状可能原因排查切入点启动慢顶层 import 大量重型库py-spy 采样 import 阶段耗时import 报错循环依赖 / 转导出缺失手动按序导入复现相对导入失效以脚本方式运行包内模块改用python -m自定义 finder 不生效注册位置、匹配逻辑在 find_spec 里打印修改代码后行为不变sys.modules 缓存 / pyc 旧缓存清缓存并重启LazyLoader 访问慢代理层开销局部变量绑定替代属性访问6. 别急着全盘优化先测量再动手最后聊点我在实际项目里的体会。import 优化虽然有效但不是所有项目都需要一上来就搞。如果你写的是长期运行的服务端进程启动时间本身影响很小那么为了延迟导入损失代码可读性和维护性得不偿失。真正需要下功夫的是 CLI、容器化服务冷启动、无服务函数、机器学习模型的在线推理入口这些场景——它们的启动延迟直接和用户体验挂钩。我的建议顺序是先用py-spy或cProfile对启动过程做一次采样确定 import 阶段到底占总耗时的多少比例。如果占比确实高再逐一拉出具体是哪些模块耗时最重针对重度模块做懒加载或结构优化。如果你连瓶颈在哪都不知道就把所有 import 都重构成__getattr__和自定义 finder大概率是给自己埋雷。我推崇的做事方式是“优化有边界”既要看到性能改进也要计算维护成本。比如延迟导入的代码确实会让模块之间的依赖关系变得更隐晦新手同事读代码时可能一脸懵。如果你的团队对这块知识储备不够至少要在代码注释里写清楚“为什么要延迟导入这个模块”以及“哪些模块只有在什么路径下才会被加载”。还有一个容易被忽视的小细节import 优化的收益不只是启动时间还能降低进程的内存峰值。因为延迟加载意味着那些非必要模块根本不会被加载进内存对于内存敏感型服务这可能比启动速度更重要。如果你准备动手我给你的实战建议是先拿项目里最大的几个依赖开刀把 pandas、torch、opencv 这类重库的导入路径全部梳理清楚然后按照“函数级延迟 - 模块级缓存 - 包级__getattr__延迟导出 - 自定义加载器”的顺序逐层推进。每一步都有明确的可回退方案也不会让你的代码在优化后变成一团乱麻。import 机制是 Python 里最容易产生“隐形性能黑洞”的地方它不像算法复杂度那样肉眼可见但影响范围比想象中大得多。理解了 import 和 importlib 的底层原理之后你再遇到启动慢的问题就不会第一时间甩锅给“Python 本身就慢”了——你会有更精确的刀去切真正浪费时间的环节。