Python 的 Decorator 在使用上和 Java 的 Annotation（以及 C# 的 Attribute）很相似，就是在方法名前面加一个 @XXX 注解来为这个方法装饰一些东西。但是，Java/C# 的 Annotation 也很让人望而却步，太过于复杂了。你要玩它，需要先了解一堆 Annotation 的类库文档，感觉几乎就是在学另外一门语言。

而 Python 使用了一种相对于 Decorator Pattern 和 Annotation 来说非常优雅的方法，这种方法不需要你去掌握什么复杂的 OO 模型或是 Annotation 的各种类库规定，完全就是语言层面的玩法：一种函数式编程的技巧。

这是我最喜欢的一个模式了，也是一个挺好玩儿的东西，这个模式动用了函数式编程的一个技术——用一个函数来构造另一个函数。

好了，我们先来点感性认识，看一个 Python 修饰器的 Hello World 代码。

代码的执行结果如下：

你可以看到如下的东西：

对于 Python 的这个 @注解语法糖（syntactic sugar）来说，当你在用某个 @decorator 来修饰某个函数func时，如下所示:

其解释器会解释成下面这样的语句：

嘿！这不就是把一个函数当参数传到另一个函数中，然后再回调吗？是的。但是，我们需要注意，那里还有一个赋值语句，把 decorator 这个函数的返回值赋值回了原来的func。

我们再来看一个带参数的玩法：

在上面这个例子中，我们可以看到：makeHtmlTag有两个参数。所以，为了让hello = makeHtmlTag(arg1, arg2)(hello)成功，makeHtmlTag必需返回一个 decorator（这就是为什么我们在makeHtmlTag中加入了real_decorator()）。

这样一来，我们就可以进入到 decorator 的逻辑中去了——decorator 得返回一个 wrapper，wrapper 里回调hello。看似那个makeHtmlTag()写得层层叠叠，但是，已经了解了本质的我们觉得写得很自然。

我们再来看一个为其它函数加缓存的示例:

上面这个例子中，是一个斐波那契数例的递归算法。我们知道，这个递归是相当没有效率的，因为会重复调用。比如：我们要计算 fib(5)，于是其分解成fib(4) + fib(3)，而fib(4)分解成fib(3) + fib(2)，fib(3)又分解成fib(2) + fib(1)……你可看到，基本上来说，fib(3),fib(2),fib(1)在整个递归过程中被调用了至少两次。

而我们用 decorator，在调用函数前查询一下缓存，如果没有才调用，有了就从缓存中返回值。一下子，这个递归从二叉树式的递归成了线性的递归。wraps的作用是保证fib的函数名不被wrapper所取代。