17370845950

装饰器通过返回闭包（inner 函数）来实现功能增强，该 inner 函数在被调用时才接收并处理实际参数（如 num），因此能自然访问调用时传入的值，而非定义时的外部作用域。

在 Python 中，@facto_decorator 语法糖本质上是函数重绑定的过程。当你写下：

@facto_decorator
def facto(num):
    if num == 1:
        return 1
    else:
        return num * facto(num - 1)

等价于：

def facto(num):
    if num == 1:
        return 1
    else:
        return num * facto(num - 1)

facto = facto_decorator(facto)  # 重新将 facto 指向装饰后的 inner 函数

此时，facto 不再指向原始函数，而是指向 facto_decorator 返回的 inner 函数。而 inner 的签名是 def inner(num): ...，它本身就是一个独立的、带参数的可调用对象。

关键点在于：
✅ inner 并不“提前知道” num 是什么；它只是定义了一个接受 num 参数的函数。
✅ 当你执行 facto(a) 时，实际调用的是 inner(a) —— 此时 a 作为实参传入，num 是形参，作用域属于 inner 的局部命名空间。
❌ facto_decorator 函数自身确实没有 num 参数，也不需要；它的职责是接收原函数 func，并返回一个新函数（inner），这个新函数才负责处理每次调用的具体参数。

因此，这不是“inner 访问了 facto_decorator 的变量”，而是典型的闭包 + 参数传递机制：

• inner 闭包捕获了外层 facto_decorator 中的 func 和 memory（形成闭包变量）；
• 同时，inner 自身声明了 num 参数，用于接收每次调用时传入的实际数值。

? 补充验证：你可以打印 facto.__name__，会发现输出 'inner'（除非使用 @functools.wraps(func) 修饰），这直观说明 facto 现在就是 inner。

⚠️ 注意事项：

• memory 是全局字典，虽在此例中可行，但在多线程或并发场景下存在风险，建议改用线程安全的缓存（如 functools.lru_cache 或 threading.Lock 保护）；
• 递归调用 facto(num-1) 实际触发的是已装饰的 facto，即持续走 inner 逻辑 —— 这正是装饰器“透明增强”的体现，也是本例能正确缓存所有中间结果（如 facto(5) 会缓存 1! 到 5!）的原因。

总结：inner 能访问 num，不是魔法，而是因为 facto(a) → inner(a)，参数按 Python 标准调用规则传递给了 inner 的形参。理解装饰器的本质是「函数工厂」，就能清晰把握闭包与参数作用域的关系。