我要评论前言
你是否也遇到过这样的场景？
项目里有一个 config.py 文件，它像个大管家，定义了项目中几乎所有的配置项。比如数据库地址、api 密钥、文件路径，甚至还包含了一些初始化函数，用来在程序启动时就加载语言模型、读取大型数据文件。
随着项目越来越复杂，这个 config.py 变得越来越臃肿。
慢慢地，你发现一个问题：哪怕只是想运行一个只用到了 config 中某个简单变量的小脚本，或者只是想查看一下命令行工具的 --help 信息，程序也要先等上好几秒，甚至几十秒。
这是因为 import config 这行代码，会立刻执行整个 config.py 文件里的所有代码。那些耗时的模型加载、文件读写操作，一个都逃不掉。这种启动延迟，在日常开发和调试中，让人感觉非常迟钝。
有没有办法让 config 变得“聪明”一点？我们希望它能做到：
import config这一步要飞快，几乎不花时间。- 只有当我们真正需要某个耗时的资源时（比如
config.big_model），它才去加载。 - 对于已经加载过的资源，不要重复加载。
- 最重要的是，所有这一切对项目里的其他模块都是透明的。其他代码依然使用
import config和config.xxx，不需要做任何修改。
今天，我们就来给这个 config.py 动个“手术”，用代理模式，来解决以上所有问题。
核心思路：找一个“代理”
我们的核心思路很简单：找一个“替身”，或者叫“代理”。
想象一下，config.py 是一栋住着很多专家的公寓楼。而我们给这栋楼雇佣了一个前台。
- 轻量的前台：任何人都先和这个前台打交道。找前台 办事非常快，因为它本身不处理具体业务。
- 按需通报：当你第一次问前台：“请帮我找一下‘模型专家’（
config.model）。” 前台才会去公寓楼里，把“模型专家”请出来。这个过程可能有点慢，因为这是专家第一次出门。 - 记住专家：一旦“模型专家”被请出来了，前台就会记住他。下次你再找“模型专家”，前台会直接让你和他对话，无需再次通报。
- 无感切换：对你来说，你感觉自己一直在和
config这个整体打交道，完全察觉不到背后还有个前台在帮你调度。
这就是我们要做的。我们把原来沉重的 config.py 重命名为 _config_loader.py（下划线开头，表示内部使用），它就是那栋“专家公寓”。然后创建一个全新的、轻量的 config.py，它就是我们的“前台代理”。
代码实现
让我们一步步构建这个代理。
第一步：准备好“公寓”
把原来所有的配置和初始化代码，原封不动地放进 configure/_config_loader.py 文件里。
# configure/_config_loader.py
print("--- [真实模块] _config_loader.py 正在被执行... ---")
# 这里有耗时的操作
# 模拟加载模型或读取大文件
# 项目中的各种配置变量
params = {"theme": "dark", "version": 1.0}
current_status = "idle"
api_key = "a-very-secret-and-long-key"
# 可能还有一些函数
def getset_params(cfg=none):
"""一个可以读取或修改全局配置的函数"""
global params
if cfg is not none:
print(f"--- [真实模块] 正在用 {cfg} 覆盖 params")
params = cfg
return params
print("--- [真实模块] _config_loader.py 执行完毕。 ---")
第二步：构建 前台代理
现在，我们来编写全新的 configure/config.py。这是整个魔法的核心。
# configure/config.py
import sys
import importlib
import threading
class lazyconfigloader:
def __init__(self):
# 使用 object.__setattr__ 来设置实例自己的属性
# 这样可以避免触发我们自定义的 __setattr__，从而防止无限递归
object.__setattr__(self, "_config_module", none)
# 为多线程环境准备一把锁
object.__setattr__(self, "_lock", threading.lock())
def _load_module_if_needed(self):
"""如果真实模块还没加载，就加锁并加载它，且只加载一次。"""
# 采用“双重检查锁定”模式，提高已加载后的访问效率
if object.__getattribute__(self, "_config_module") is none:
with object.__getattribute__(self, "_lock"):
if object.__getattribute__(self, "_config_module") is none:
print("[代理] 首次访问，开始加载 _config_loader 模块...")
module = importlib.import_module("._config_loader", __package__)
object.__setattr__(self, "_config_module", module)
print("[代理] _config_loader 模块加载完毕。")
def __getattr__(self, name):
"""
代理读操作：当访问 config.xxx 时，如果实例上找不到 xxx，此方法被调用。
"""
self._load_module_if_needed()
print(f"[代理] 正在获取属性: {name}")
return getattr(object.__getattribute__(self, "_config_module"), name)
def __setattr__(self, name, value):
"""
代理写操作：当执行 config.xxx = yyy 时，此方法被调用。
"""
self._load_module_if_needed()
print(f"[代理] 正在设置属性: {name} = {value}")
setattr(object.__getattribute__(self, "_config_module"), name, value)
# 用代理类的实例，替换掉 python 加载系统中的自己。
sys.modules[__name__] = lazyconfigloader()
理解背后的魔术方法
代码看起来不复杂，但里面藏着几个 python 的核心机制。
魔法一：__getattr__和__setattr__
这两个是 python 的“魔法方法”。
__getattr__(self, name): 当你试图访问一个对象上不存在的属性时，python 会自动调用这个方法。我们的lazyconfigloader实例自己身上是空的，所以任何config.params或config.getset_params这样的访问，都会触发它。它就像一个捕获所有“读”请求的网。__setattr__(self, name, value): 这个方法会拦截所有的属性赋值操作。当你执行config.current_status = 'running'时，它会捕获这个“写”请求。
在这两个方法内部，我们都先确保真实模块已被加载，然后把操作（读或写）转发给那个真实的模块对象。
魔法二：object.__setattr__和object.__getattribute__
你可能注意到，在类内部我们没有用 self._config_module = ...，而是用了 object.__setattr__(self, ...)。这是为了防止“我拦截我自己”的尴尬情况。如果在 __setattr__ 中再进行赋值，就会触发自己，导致无限循环。通过调用 object 基类的原始方法，我们绕过了自己的拦截器，安全地操作实例自身的属性。
魔法三：sys.modules[__name__] = lazyconfigloader()
这是整个方案的“临门一脚”。python 的 import 机制有一个缓存区，叫做 sys.modules，记录了所有已加载的模块。我们的代码利用了这个机制，在 config.py 文件被执行的最后，做了一件“偷天换日”的事：它把自己在 sys.modules 里的条目，从一个普通的模块对象，替换成了一个 lazyconfigloader 类的实例。
从此以后，任何其他模块执行 from videotrans.configure import config，它们拿到的不再是一个模块，而是我们那个神通广大的代理实例。但因为这个实例完美地模仿了模块的行为，所以对于使用者来说，一切看起来都和原来一样。
解决一个新问题：找回 ide 的代码提示
这个模式有一个副作用：ide（如 vscode, pycharm）会变得“困惑”。因为它只看到了 config.py 里的 lazyconfigloader 类，它根本不知道 config 对象上还会有 params, api_key 这些属性。于是，失去了宝贵的代码自动补全和“跳转到定义”功能。
幸运的是，python 提供了一种优雅的解决方案：类型存根文件 (.pyi)。
.pyi 文件就像是模块的“说明书”，它只描述模块里有什么东西、类型是什么，但没有任何具体实现。这个“说明书”是专门给 ide 和类型检查工具看的，而 python 在实际运行时会忽略它。
第三步：为 config 模块创建“说明书”
在 configure/ 目录下，创建一个新文件 config.pyi。
# configure/config.pyi # 这个文件只给 ide 看，用于代码提示和类型检查 from typing import any, dict # 我们在这里只声明变量和函数的“签名”，不提供实现 # 类型可以写得精确，也可以用 any 简单带过 params: dict[str, any] current_status: str api_key: str def getset_params(cfg: dict[str, any] | none = none) -> dict[str, any]: ...
我们只需要把 _config_loader.py 中所有需要被外部访问的变量和函数，都在 .pyi 文件里声明一遍。函数体用 ... 代替即可。
有了这份“说明书”后：
- ide 会读取
.pyi文件，于是它就知道了config模块上有params、current_status等属性，代码补全和跳转功能就都回来了。 - python 解释器 在运行时会忽略
.pyi文件，依然执行config.py里的懒加载逻辑，保证了高性能。
我们完美地实现了“对人友好”和“对机器友好”的统一。
看看效果
创建一个 main.py 来使用这个新的 config。
# main.py
print("程序启动，准备导入 config 模块...")
from videotrans.configure import config
print("导入 config 完成。此时真实模块并未加载。")
print("\n--- 第一次访问 ---")
print(f"读取配置: config.api_key = {config.api_key}")
# ... (后续测试代码不变) ...
运行 main.py，你会看到和之前一样的输出，证明我们的懒加载机制在正常工作。同时，在 ide 中编写这段代码时，你会发现输入 config. 后，api_key, params 等提示又回来了。
总结一下
通过“代理模式”和 .pyi 存根文件，成功地将一个臃肿、拖慢启动速度的配置模块，改造成了一个轻量、高效、按需加载，并且对开发者和 ide 都十分友好的智能模块。
这个方法不仅限于 config 文件。任何需要加载昂贵资源（如机器学习模型、大型数据集、数据库连接池）的模块，都可以用这种方式进行优化。将对象的创建和初始化推迟到真正需要它的时候。
以上就是python如何优化config模块提升启动速度的详细内容，更多关于python config模块的资料请关注代码网其它相关文章！
发表评论