1. 周五晚上的“黑色 3 分钟”
先跟你讲讲我是怎么栽跟头的。
那是个周五晚上，22:57，我美滋滋地敲完最后一行代码，准备发版后下班撸串。CI/CD 流水线启动，Docker 镜像构建，一切看起来岁月静好。
结果，容器启动失败了。不是报错，是超时。
K8s 的健康检查死活过不去，3 分钟探针超时，直接 Kill Pod。我一脸懵，本地跑得好好的，怎么上了环境就卡住？
我盯着启动日志，发现程序在 import 某个模块那里卡了将近两分钟。那个模块顶部，我写了一个美滋滋的“性能监控装饰器”，用来记录每个接口的耗时。装饰器里为了发监控日志，初始化了一个数据库连接池。
我的第一反应是：“不对啊，我又没调用那个接口，连数据库干嘛？”
但现实啪啪打脸——它就是连了。就在模块被加载的那一瞬间，它偷偷摸摸地把活儿全干了。
这就是 Python 装饰器最阴险的地方：你以为它在等你发号施令，其实它在看到你的第一眼就已经动手了。
2. 还原“案发现场”：什么都没干，但它干了
咱们把那个场景简化成几行代码，你看看问题出在哪。
import time
def monitor_decorator(func):
print(f"⚠️ 正在初始化监控模块，绑定函数：{func.__name__}")
# 模拟这里有个数据库连接池初始化，耗时 3 秒
time.sleep(3)
print("✅ 监控连接池已就绪")
def wrapper(*args, **kwargs):
print(f"开始执行 {func.__name__}")
result = func(*args, **kwargs)
print(f"执行结束 {func.__name__}")
return result
return wrapper
@monitor_decorator
def get_user_info(user_id):
return f"用户 {user_id} 的数据"
# 注意看！到这里为止，我一次都没调用 get_user_info()
# 我只是把文件保存了，或者只是 import 了这个模块。
请问，控制台会输出什么？
如果你以为是“啥也不输出，因为没调用函数”，那你就跟我一样踩坑了。
现实输出：
⚠️ 正在初始化监控模块，绑定函数：get_user_info
（等 3 秒）
✅ 监控连接池已就绪
看到了吗？我连 get_user_info() 都没调用，它凭什么初始化连接池？凭什么让我等 3 秒？
这就是 Python 语法糖背后藏着的真相——在你按下回车或模块被导入的瞬间，装饰器外层的代码已经跑完了。
3. 撕开语法糖：你到底对 @ 做了什么？
要想知道它为什么“偷跑”，得先弄清楚 Python 解释器看到 @monitor_decorator 这行时，脑子里的翻译逻辑是什么。
我们通常觉得 @ 是个“标记”或者“注解”，像 Java 那样只是个元数据。大错特错。
@ 在 Python 里是可执行语句。它的本质是函数调用。
你写的这一段：
@monitor_decorator
def get_user_info(user_id):
return f"用户 {user_id} 的数据"
Python 解释器在读取定义的时候，会把它翻译成下面这行代码去执行：
def get_user_info(user_id):
return f"用户 {user_id} 的数据"
get_user_info = monitor_decorator(get_user_info) # 就是这一句！
看清楚了吗？monitor_decorator(get_user_info) 是带括号的调用。
只要带括号，Python 就会立即执行这个函数。它管你里面是 print、time.sleep 还是连接数据库？照跑不误。
所以，装饰器的执行时机从来都不是“等你调用原函数的时候”，而是“Python 编译完这个函数的代码体，准备把函数名绑定到变量上的那一刻”。
4. 抓住元凶：Python 的两个“时间线”
为什么我们总会产生“它不该现在执行”的错觉？
因为我们在脑子里把 Python 程序的运行想象成了一条“流水线”：定义 -> 调用。我们天然觉得 def 只是“记录一下”的意思。
但 Python 内部其实是两条截然不同的时间线：
时间线一：定义/加载阶段（偷跑阶段）
Python 从上到下扫描 .py 文件。它要搞清楚这个文件里有哪些东西。
- 遇到
def，它会编译函数体内部的字节码，但先不运行里面的代码。 - 但是！如果遇到
@，它管不住自己，必须立即调用装饰器函数，把下面的函数对象塞进去。 - 这一步不是为了运行你的业务，而是为了构建这个函数对象。构建完了，它才会把最终返回的
wrapper赋值给get_user_info这个名字。
时间线二：运行/调用阶段（你本以为的阶段）
只有当你显式地写下 get_user_info(123) 时，才会触发时间线二。
- 这时候跑的是
wrapper函数里面的代码。 wrapper里面的func()才会去真正执行你当初写的return f"用户..."。
一句话概括：
装饰器外层（接收 func 的那层）属于“构建期”，装饰器内层（wrapper）才属于“运行期”。
构建期搞连接池，等于你在盖房子打地基的时候就把水管接上了自来水厂，水能不喷你一脸吗？
5. 进阶暴击：你说的“传参”到底是怎么回事？
你的标题里提到了“函数传参时偷偷执行”。很多人在这个地方被绕晕，我来帮你把最后一层窗户纸捅破。
如果我要带参数的装饰器，比如这样：
@retry(times=3)
def call_api():
return requests.get("...")
这里的 times=3 是“函数传参”吧？你是不是以为 Python 会先记录一下 times=3，等调用 call_api 时再一起处理？
Too young too simple。上面的代码，Python 解释器会拆成两步来立即执行：
第一步： 执行 retry(times=3)。 因为带了括号，Python 不管三七二十一，先调用 retry 函数，把 times=3 传进去。这返回一个中间产物，我们叫它 real_decorator。
第二步： 执行 real_decorator(call_api)。 刚才返回的中间产物，立刻又被加了个括号，把 call_api 函数对象塞进去调用。
这两步，发生在你按下运行按钮的前 0.01 秒，发生在你的 call_api() 被调用的前 10 分钟。
这就是为什么你如果在装饰器里加了参数，然后在这个装饰器外层打印日志，你会发现模块一加载日志就出来了，甚至还没等你写 if __name__ == "__main__":。
6. 这种“偷跑”会给你埋下哪些雷？
不仅仅是启动慢，这种机制会引发几种极其恶心的生产事故：
第一，循环导入崩溃。假设你的装饰器在 utils.py，它需要读取 config.py 里的某个全局变量。而 config.py 又需要导入 utils.py 里的工具函数。由于装饰器在模块加载时执行，它立即去读 config 变量，此时 config 还没加载完，结果是 None 或者直接报 AttributeError。你的项目连个完整报错堆栈都看不到，直接闪退。
第二，滥用缓存导致内存泄露。有些人喜欢在装饰器里用字典做缓存（cache = {}），心想“反正我只定义一次”。但因为装饰器在加载时执行，如果你不小心在装饰器外层引用了大对象，这个对象永远不会被垃圾回收，因为它在模块作用域里被死死拽住了。随着服务运行，内存悄悄上涨，直到 OOM。
第三，单测变“集成测试”。写单元测试时，我只需要测试一个纯函数逻辑。结果因为这个函数头顶上挂着个装饰器，一导入模块，装饰器跑去连 Redis、连 MySQL。单测跑得比集成测试还慢，逼得我每次跑单测都得 mock 掉装饰器，烦不胜烦。
7. 怎么治它？把“急性子”变成“懒加载”
坑踩完了，怎么填？
既然知道装饰器外层是急性子，那我们就把所有的“重活”和“外部依赖”全部塞进 wrapper 里面。
错误示范（经典反面教材）：
def my_decorator(func):
# 危险区：定义时就执行，绝对禁止放初始化！
db = connect_to_mongo()
logger = init_log_sdk()
def wrapper(*args, **kwargs):
return func(*args, **kwargs)
return wrapper
正确姿势（安全改造）：
def my_decorator(func):
# 这里只动口不动手，只做函数替换，绝不搞 IO 操作
def wrapper(*args, **kwargs):
# 安全区：只有真正调用时才会执行
# 如果连接失败，也是调用时才报错，不会阻塞启动
db = connect_to_mongo()
logger = init_log_sdk()
return func(*args, **kwargs)
return wrapper
如果实在想在定义时干点啥，也仅限于纯内存操作，比如拼个字符串、算个数学公式，或者把 func 存下来。凡是涉及 print、open、connect、sleep 的，一概扔进 wrapper。
高阶玩法：单例懒加载如果连接池确实全局只需要一个，又不想每次都创建，可以在 wrapper 里加一层判断：
def my_decorator(func):
db_pool = None # 定义时只是占个坑
def wrapper(*args, **kwargs):
nonlocal db_pool
if db_pool is None:
print("只有第一次调用时才会真正连接！")
db_pool = connect_to_mongo()
return func(*args, **kwargs)
return wrapper
这样一来，哪怕你的模块被 100 个地方导入，只要没人调这个函数，数据库连接就永远不会建立。第一次调用时建立，之后复用。 既解决了启动阻塞，又解决了性能问题。
8. 最后再说一句“保命”的
经历过这次周五晚上的事故后，我给自己定了一条死规矩，也送给你：
写装饰器时，把
def wrapper这一行当作“警戒线”。警戒线以上的代码，默认会在你导入模块时执行；警戒线以下的代码，才会在你调用函数时执行。
下次你再看到别人写的装饰器，或者在 @ 下面写逻辑时，多问自己一句：“这行代码如果真的现在就跑，我扛得住吗？”
如果扛不住，别犹豫，往里缩一格缩进，塞进 wrapper 里面去。
Python 的装饰器是一把极其锋利的刀，能优雅地解耦日志、鉴权、重试等横切关注点。但刀用错了地方，切到的就是自己的手。理解了它“偷跑”的本质，你就从被坑的玩家，变成了掌控局面的老手。
记住了，没有调用的调用，才是最致命的调用。 今后再遇到启动慢或者诡异的导入报错，记得先看看头顶的 @，说不定它正躲在角落里偷偷冲你坏笑呢。
