我被 Python 装饰器坑了三个月，直到搞懂它的"套路"

首页

业界动态

热心网友

转载

2026-04-20

别再把装饰器当成高深莫测的高级语法来回避了

装饰器的本质，说到底就是一个函数包裹函数的技巧。想彻底掌握它，只需要搞清楚三件事：谁包裹谁、参数怎么传递、元数据怎么保留。

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

先讲一个真实发生过的故事。

去年有个接口日志项目，需求是记录每个API的调用时间、请求参数和返回状态。团队里一位经验丰富的同事建议用装饰器，说写个@log标签就能搞定。听起来很美好，对吧？于是照着网上的文档抄了一段代码，运行——结果直接报错：TypeError: wrapper() missing 1 required positional argument。

对着屏幕愣了半天。文档明明就是这样写的，问题出在哪里？

后来排查才发现，抄的那篇博客太老了，用的是Python 2的写法。到了Python 3，连个清晰的错误提示都没有，就扔给你一句“缺少参数”。这个细节差点让项目延期。也正是那次经历让人意识到，对装饰器这种工具，必须从原理到实战彻底搞清楚，不能停留在半懂不懂、照抄代码的阶段。

今天，就把那些踩过的坑、总结的经验、提炼的套路一次性讲清楚。不堆砌概念，不照本宣科，直接聚焦你在实际编码中会遇到的问题。

一、装饰器到底是什么？

很多资料会说“装饰器是一种闭包”，这话没错，但看完你可能还是不会写。

换个更直观的理解方式：装饰器就是函数的“包装膜”。

想象一下去水果店买水果。水果本身没变，但套上包装盒之后，功能就多了：可以保鲜，可以印上品牌Logo，还能加个防伪标签。装饰器干的就是这个事——在不改动原函数内部代码的前提下，为函数增添额外的功能。

最常见的应用场景有哪些？计时、登录校验、日志记录、性能监控。这些需求如果每个函数都手动写一遍，代码会变得冗长且难以维护。装饰器的价值就在于，让你只写一次核心逻辑，然后像贴标签一样应用到任何需要的地方。

import time

def timer(func):
    def wrapper(*args, **kwargs):
        start = time.time()
        result = func(*args, **kwargs)
        end = time.time()
        print(f"函数 {func.__name__} 耗时 {end - start:.4f} 秒")
        return result
    return wrapper

@timer
def slow_function():
    time.sleep(1)
    return "Done"

slow_function()

看，slow_function本身没有任何改动，但贴上@timer之后，就自动拥有了计时能力。这就是装饰器的核心魅力——增强函数功能，但不污染函数本身的纯净性。

二、它为什么能工作？

很多人会用装饰器，但未必清楚其背后的运作机制。看懂下面这段拆解，你就能自己创造装饰器了：

def slow_function():
    return "Done"

def timer(func):
    def wrapper():
        start = time.time()
        result = func()
        end = time.time()
        print(f"耗时 {end - start:.4f} 秒")
        return result
    return wrapper

# 这一行就是 @timer 的本质
slow_function = timer(slow_function)

装饰器的语法糖@timer，其实就是上面那行手动包装代码的简写形式。

所以，装饰器的本质可以归结为：一个高阶函数，它接收一个函数作为输入，经过包装后，返回另一个函数作为输出。

三、踩坑实录：那些让新手崩溃的瞬间

1. 坑一：*args, **kwargs写错一个符号

def my_decorator(func):
    def wrapper(*args, **kwargs):  # 星号必须带
        print("开始执行")
        return func(*args, **kwargs)  # 这里也是
    return wrapper

把*args写成args，或者把**kwargs写成kwargs，Python通常会报一个比较隐晦的错误。关键在于，*是解包操作。func(*args)是把元组里的每个元素拆开传给函数；而func(args)则是把整个元组当作一个参数传进去，函数签名自然就对不上了。

自检方法很简单：用签名复杂的函数来测试你的装饰器。

@my_decorator
def complex_func(a, b=10, *args, **kwargs):
    print(f"a={a}, b={b}, args={args}, kwargs={kwargs}")

complex_func(1, 2, 3, 4, name="test")

2. 坑二：装饰器带参数，写成了套娃

def log(level="INFO"):
    def decorator(func):
        def wrapper(*args, **kwargs):
            print(f"[{level}] 调用 {func.__name__}")
            return func(*args, **kwargs)
        return wrapper
    return decorator

@log("ERROR")
def run():
    pass

这里有个记忆诀窍：带参数的装饰器，本质是“工厂的工厂”。

拆解一下这三层各自负责什么：

第一层log(“ERROR”)负责接收参数，并返回一个真正的装饰器函数。
第二层decorator负责接收被装饰的函数。
第三层wrapper才是真正包裹原函数、执行增强逻辑的地方。

所以，@log(“ERROR”)等价于run = log(“ERROR”)(run)。

3. 坑三：装饰器改变了原函数的“身份”

@timer
def add(a, b):
    """两数相加，返回结果"""
    return a + b

print(add.__name__)   # 输出什么？ wrapper  ← 函数名丢了
print(add.__doc__)    # 输出什么？ None    ← 文档丢了

这个问题很关键。很多Web框架会根据函数名和文档字符串来生成路由或进行参数校验。元数据一旦丢失，轻则路由名变成莫名其妙的wrapper，重则导致整个应用行为异常。

解决方法只有一行代码：

import functools

def timer(func):
    @functools.wraps(func)  # 把原函数的元数据复制过来
    def wrapper(*args, **kwargs):
        start = time.time()
        result = func(*args, **kwargs)
        end = time.time()
        print(f"耗时 {end - start:.4f} 秒")
        return result
    return wrapper

加上@functools.wraps(func)这一行，原函数的__name__、__doc__、__annotations__等元数据就全部保留下来了。这行代码没有理由不写，务必养成习惯。

4. 坑四：装饰器返回了None

def bad_decorator(func):
    def wrapper(*args, **kwargs):
        print("做一些操作")
        func(*args, **kwargs)  # 没有return！
    return wrapper

@bad_decorator
def get_data():
    return [1, 2, 3]

result = get_data()
print(result)  # 输出：None ← 返回值丢了

记住一个铁律：装饰器内部的wrapper函数，永远要return原函数的执行结果。否则，被装饰的函数就失去了返回值。

四、实战：写一个带缓存的装饰器

import functools, time

def memoize(ttl=300):
    """
    带过期时间的内存缓存装饰器
    ttl: 缓存有效期（秒），默认5分钟
    """
    cache = {}

    def decorator(func):
        @functools.wraps(func)
        def wrapper(*args, **kwargs):
            key = str(args) + str(sorted(kwargs.items()))
            now = time.time()

            if key in cache:
                val, t, expire = cache[key]
                if now - t < expire:
                    print(f"命中缓存 (剩余 {expire - (now - t):.0f}s)")
                    return val

            result = func(*args, **kwargs)
            cache[key] = (result, now, ttl)
            print("缓存未命中，执行函数")
            return result
        return wrapper
    return decorator

@memoize(ttl=10)
def fetch_api(user_id, include_history=True):
    time.sleep(2)  # 假设每次请求耗时2秒
    return {"user_id": user_id, "data": [1, 2, 3]}

data1 = fetch_api(1001)  # 耗时2秒
data2 = fetch_api(1001)  # 0秒返回，命中缓存
data3 = fetch_api(1002)  # 耗时2秒，不同参数

同样的参数在10秒内重复调用，2秒的请求瞬间变成0秒返回。这个模式稍加扩展，配合Redis，就能做成一个分布式的缓存装饰器。

五、类装饰器：不是函数也可以被装饰

1. 单例模式装饰器

def singleton(cls):
    instances = {}

    @functools.wraps(cls)
    def get_instance(*args, **kwargs):
        if cls not in instances:
            instances[cls] = cls(*args, **kwargs)
        return instances[cls]
    return get_instance

@singleton
class DatabaseConnection:
    def __init__(self):
        print("创建数据库连接...")
        self.connected = True

db1 = DatabaseConnection()
db2 = DatabaseConnection()
db3 = DatabaseConnection()
print(db1 is db2 is db3)  # True，只初始化一次

虽然调用了三次DatabaseConnection()，但__init__只执行了一次。这种模式非常适合数据库连接池、全局配置管理器、线程池或日志实例等场景。

2. 路由注册装饰器

class Router:
    routes = {}

    @classmethod
    def route(cls, path):
        def decorator(func):
            cls.routes[path] = func
            print(f"注册路由: {path} -> {func.__name__}")
            return func
        return decorator

class MyApp(Router):
    @Router.route("/home")
    def home(self): return "Welcome home"

    @Router.route("/about")
    def about(self): return "About us"

print(MyApp.routes)

3. 多个装饰器的叠加顺序

@log_decorator
@timer_decorator
def process():
    time.sleep(0.1)
    return "Done"

装饰器是从下往上依次应用的。可以想象成从里到外穿衣服：先穿内衣@timer_decorator，再套外套@log_decorator。

从调用角度看：process()先经过外套log_decorator，再进入内衣timer_decorator，最后才到达process函数本体。这也解释了为什么内层装饰器必须加@functools.wraps——它确保了外层装饰器看到的是真实的函数名，而不是一个wrapper。

六、真实项目的两个实用场景

场景一：重试机制

import functools, time, logging
logger = logging.getLogger(__name__)

def retry(max_attempts=3, delay=1):
    def decorator(func):
        @functools.wraps(func)
        def wrapper(*args, **kwargs):
            for attempt in range(max_attempts):
                try:
                    return func(*args, **kwargs)
                except Exception as e:
                    if attempt == max_attempts - 1:
                        raise
                    logger.warning(f"第{attempt+1}次失败，{delay}s后重试: {e}")
                    time.sleep(delay)
        return wrapper
    return decorator

@retry(max_attempts=3, delay=2)
def call_api(url):
    import random
    if random.random() < 0.7:
        raise ConnectionError("网络超时")
    return "成功"

场景二：权限校验

def requires_auth(permission):
    def decorator(func):
        @functools.wraps(func)
        def wrapper(*args, **kwargs):
            user = get_current_user()
            if permission not in user.permissions:
                raise PermissionError(f"需要权限: {permission}")
            return func(*args, **kwargs)
        return wrapper
    return decorator

@requires_auth("admin")
def delete_user(user_id): pass

@requires_auth("finance")
def export_report(): pass

这样一来，权限校验逻辑和业务逻辑完全分离，修改一处不会影响另一处，代码的清晰度和可维护性大大提升。