类作为装饰器时为何丢失self？

小伙伴们有没有觉得学习文章很有意思？有意思就对了！今天就给大家带来《类作为装饰器时为何丢失self？》，以下内容将会涉及到，若是在学习中对其中部分知识点有疑问，或许看了本文就能帮到你！

当用类实现装饰器的包装逻辑时，因未实现描述符协议（descriptor protocol），无法自动绑定实例方法中的`self`，导致调用时需手动传入对象；而函数式装饰器天然支持该协议，能正确完成方法绑定。

在 Python 中，实例方法的自动 self 绑定并非语法糖，而是由描述符协议（即 __get__ 方法）驱动的底层机制。当访问 obj.method 时，Python 会检查 method 是否实现了 __get__；若实现，则调用 method.__get__(obj, type(obj))，返回一个已绑定 self 的可调用对象（如 bound method）。普通函数（function 类型）内置了这一行为，因此用函数作装饰器包装器（如 @decorator）时，返回的 wrapper 函数仍可被正确绑定。

但自定义类（如 broken_decorator 中的 Wrapper）默认不实现 __get__，因此 three.plus_ 查找时直接返回该类实例本身，而非绑定后的调用体。调用 three.plus_(4) 实际执行的是 Wrapper().__call__(three, 4) —— 看似合理，却因 __call__ 的第一个参数被误认为 self（即 Wrapper 实例），而原方法期望的 MyClass 实例 three 反被当作 y 参数，造成语义错乱。示例中 three.plus_(MyClass(4), 4) 能“运行”，恰恰暴露了这种失配：你被迫显式传入 MyClass(4) 作为第一个参数，它被 wrapper.__call__ 当作 my_class_self，从而输出 4 + 4 = 8，完全偏离预期。

✅ 正确修复方式是让包装类实现描述符协议：

def broken_decorator(func):
    class Wrapper:
        def __call__(self, my_class_self, y):
            return func(my_class_self, y)

        def __get__(self, obj, objtype=None):
            if obj is None:  # 访问类属性时返回自身（如 MyClass.plus_）
                return self
            # 返回一个绑定 obj 的代理对象
            from functools import partial
            return partial(self.__call__, obj)

    return Wrapper()

然而，正如答案所强调：这并非推荐做法。手动实现 __get__ 易出错（需区分实例/类访问、处理 staticmethod/classmethod 边界）、性能更低，且绝大多数场景下，闭包函数已足够强大：

def decorator_with_state(func):
    # 用闭包保存状态，无需类
    call_count = 0
    def wrapper(self, y):
        nonlocal call_count
        call_count += 1
        print(f"[Call #{call_count}]")
        return func(self, y)
    return wrapper

? 总结：

• ✅ 优先使用函数式装饰器（含闭包），简洁、高效、符合 Python 惯例；
• ⚠️ 仅当必须封装复杂状态机、需多态接口或深度定制调用生命周期时，才考虑带 __get__ 的描述符类；
• ❌ 切勿为“看起来更面向对象”而盲目用类替代函数——Python 的描述符机制早已为函数优化就绪，强行绕过只会增加维护成本。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《类作为装饰器时为何丢失self？》文章吧，也可关注golang学习网公众号了解相关技术文章。