functools 模块中的 lru_cache 和 wraps-Python教程-PHP中文网

lru_cache通过缓存函数结果提升性能，wraps保留被装饰函数的元信息以确保代码可维护性。两者在优化与调试中互补使用，适用于递归、I/O操作等重复计算场景，且需合理配置maxsize和typed参数以平衡性能与内存开销。

functools 模块中的 lru_cache 和 wraps

functools

登录后复制

模块中的

lru_cache

登录后复制

和

wraps

登录后复制

是Python开发者工具箱里两把非常趁手的利器，它们一个专注于性能优化，另一个则关乎代码的可维护性和健壮性。简单来说，

lru_cache

登录后复制

可以智能地缓存函数调用的结果，避免重复计算，而

wraps

登录后复制

则能确保我们在使用装饰器时，不会丢失被装饰函数的元信息。它们虽然解决的问题不同，但常常在构建高性能且易于调试的复杂系统时，以一种互补的方式出现。

解决方案

在Python的日常开发中，我们总会遇到需要权衡性能与代码清晰度的问题。

functools

登录后复制

模块正是为了解决这类问题而生。

lru_cache

登录后复制

，全称“Least Recently Used Cache”，是一种缓存策略，它会记住最近被调用的函数及其结果。当一个函数被多次以相同的参数调用时，

lru_cache

登录后复制

会直接返回之前缓存的结果，而不是重新执行函数体。这对于那些计算成本高昂、或者需要进行I/O操作的函数来说，简直是性能的救星。想象一下，一个需要从数据库查询数据的函数，如果每次调用都去查一次，那效率可想而知。但如果数据在短时间内不会变化，

lru_cache

登录后复制

就能让它瞬间返回结果。

import time
from functools import lru_cache

@lru_cache(maxsize=128) # 默认缓存128个最近的调用
def expensive_calculation(a, b):
    print(f"Calculating {a} + {b}...")
    time.sleep(1) # 模拟耗时操作
    return a + b

print(expensive_calculation(1, 2)) # 第一次计算
print(expensive_calculation(3, 4)) # 第二次计算
print(expensive_calculation(1, 2)) # 从缓存中获取
print(expensive_calculation(3, 4)) # 从缓存中获取

登录后复制

运行这段代码，你会发现前两次调用有明显的延迟，而后两次几乎是瞬间返回，这就是

lru_cache

登录后复制

的魔力。它通过在内存中维护一个字典来存储参数到结果的映射，并利用双向链表来管理LRU策略，确保当缓存达到

maxsize

登录后复制

时，最久未使用的项会被淘汰。

而

wraps

登录后复制

则是一个相对更“幕后”的工具，它主要用于自定义装饰器时。装饰器本质上是一个函数，它接受一个函数作为参数，并返回一个新的函数（通常是内部定义的wrapper函数）。问题在于，这个新的wrapper函数会覆盖掉原始函数的元数据，比如它的

__name__

登录后复制

（函数名）、

__doc__

登录后复制

（文档字符串）、

__module__

登录后复制

（所在模块）以及

__annotations__

登录后复制

（类型注解）等。这对于调试、文档生成或者其他依赖函数元信息的工具来说，会造成很大的困扰。

functools.wraps

登录后复制

的作用就是将原始函数的这些元数据“拷贝”到wrapper函数上。它本身也是一个装饰器，通常用在wrapper函数上：

from functools import wraps

def my_logging_decorator(func):
    @wraps(func) # 关键在这里！
    def wrapper(*args, **kwargs):
        print(f"Calling function: {func.__name__} with args: {args}, kwargs: {kwargs}")
        result = func(*args, **kwargs)
        print(f"Function {func.__name__} finished. Result: {result}")
        return result
    return wrapper

@my_logging_decorator
def add(x, y):
    """This function adds two numbers."""
    return x + y

print(add(5, 3))
print(f"Function name: {add.__name__}")
print(f"Function docstring: {add.__doc__}")

登录后复制

如果没有

@wraps(func)

登录后复制

，

add.__name__

登录后复制

会是

'wrapper'

登录后复制

，

add.__doc__

登录后复制

会是

None

登录后复制

（或者

wrapper

登录后复制

自己的docstring），而不是我们期望的

'add'

登录后复制

和

'This function adds two numbers.'

登录后复制

。

wraps

登录后复制

确保了即使函数被装饰了，它的身份信息依然得以保留，这对于代码的健壮性和可维护性至关重要。

lru_cache

登录后复制

在哪些场景下能显著提升Python应用的性能？

lru_cache

登录后复制

的威力，我个人认为，主要体现在那些“重复工作”的场景。当你发现你的程序在做着同样的计算，或者从同样的地方获取同样的数据，那么

lru_cache

登录后复制

就有了用武之地。

最经典的例子就是递归函数，特别是那些带有重叠子问题（overlapping subproblems）的递归，比如计算斐波那契数列。没有缓存的斐波那契函数，其时间复杂度是指数级的，因为它会重复计算很多次相同的值。但只要加上一个

@lru_cache

登录后复制

，瞬间就能把性能提升到线性级别，简直是魔法。

@lru_cache(maxsize=None) # maxsize=None表示不限制缓存大小
def fibonacci(n):
    if n <= 1:
        return n
    return fibonacci(n - 1) + fibonacci(n - 2)

# print(fibonacci(30)) # 很快
# print(fibonacci.cache_info()) # 可以查看缓存命中率等信息

登录后复制

其次，I/O密集型操作是

lru_cache

登录后复制

的另一个主战场。设想一个Web应用，它可能需要频繁地查询某个配置项、某个用户数据或者某个商品信息，而这些数据在短时间内可能不会发生变化。如果每次请求都去数据库或者外部API拉取，那网络延迟和数据库负载都会成为瓶颈。在这种情况下，给数据访问层函数加上

lru_cache

登录后复制

，就能大大减少实际的I/O操作，显著提升响应速度。我曾在一个数据分析工具中用它缓存了对一个大型CSV文件的解析结果，避免了每次筛选数据都重新读取文件，效果立竿见影。

再者，计算密集型但输入有限或重复的函数也受益匪浅。比如，某个机器学习模型需要对输入数据进行复杂的预处理，如果这些预处理步骤对于相同的输入总是产生相同的结果，那么缓存这些结果就能避免不必要的重复计算。或者，在一些需要进行大量组合排列、穷举搜索的算法中，如果中间结果可以复用，

lru_cache

登录后复制

就能将这些重复计算的开销降到最低。

总的来说，当一个函数满足以下条件时，

lru_cache

登录后复制

通常能带来显著的性能提升：

纯函数：函数的输出只由输入决定，没有副作用（side effects）。
输入参数可哈希：这是缓存键的要求。
计算成本高昂：函数执行时间较长。
调用频繁且输入重复：有较高的缓存命中率。

为什么自定义装饰器时，

functools.wraps

登录后复制

是不可或缺的？

functools.wraps

登录后复制

的重要性，说实话，在初学Python时很容易被忽视。你可能写了一个装饰器，它功能正常，代码跑得好好的，但过了一段时间，当你或者你的同事尝试去调试、测试或者仅仅是查看那个被装饰的函数时，就会发现一些奇怪的现象。这就是

wraps

登录后复制

缺席的后果。

Python的函数，不仅仅是一段可执行的代码，它还携带了丰富的元数据，比如

__name__

登录后复制

（函数名）、

__doc__

登录后复制

（文档字符串）、

__module__

登录后复制

（定义函数所在的模块）、

__annotations__

登录后复制

（类型提示）、

__qualname__

登录后复制

（限定名）等等。这些元数据对于代码的可读性、可维护性和工具支持至关重要。

百度文心百中

百度大模型语义搜索体验中心

查看详情

当你创建一个装饰器时，通常会返回一个内部定义的

wrapper

登录后复制

函数。如果没有

@wraps(func)

登录后复制

，那么被装饰后的函数，它的

__name__

登录后复制

会变成

wrapper

登录后复制

，它的

__doc__

登录后复制

会变成

wrapper

登录后复制

的文档字符串（或者

None

登录后复制

），而不是原始函数的。

这会带来一系列问题：

调试困难：当你在调试器中查看调用栈时，你会看到一系列
```
wrapper
```
登录后复制
，而不是原始的函数名，这会让你很难理解代码的实际执行路径。
文档生成失真：Sphinx或其他文档生成工具在提取函数信息时，会得到错误的函数名和文档。
测试框架误判：一些测试框架可能会基于函数名或签名来识别测试用例，
```
wraps
```
登录后复制
的缺失会导致它们无法正确识别。
内省工具失效：依赖
```
inspect
```
登录后复制
模块进行函数签名检查、参数获取的工具，会得到
```
wrapper
```
登录后复制
的签名，而不是原始函数的。
用户体验下降：当用户尝试通过
```
help(decorated_function)
```
登录后复制
来获取帮助时，看到的是装饰器内部的实现细节，而不是原始函数的用途说明。

我曾经在一个项目中遇到过一个恼人的bug，一个第三方库在内部尝试通过

func.__name__

登录后复制

来判断某个函数是否属于某个特定类型，结果因为我们自定义的装饰器没有使用

wraps

登录后复制

，导致那个库始终无法正确识别我们的函数，最终定位到问题时，才深刻体会到

wraps

登录后复制

的“无名英雄”地位。它不直接影响功能，但它保障了Python函数作为“一等公民”的完整性。所以，我的建议是：凡是自定义装饰器，无条件地加上
@wraps(func)
登录后复制
，这应该成为一种习惯。

lru_cache

登录后复制

的

maxsize

登录后复制

和

typed

登录后复制

参数应如何合理配置以避免潜在问题？

lru_cache

登录后复制

确实很强大，但它的

maxsize

登录后复制

和

typed

登录后复制

参数配置不当，也可能带来一些意想不到的问题。这就像一把双刃剑，用得好能事半功倍，用不好则可能适得其反。

关于

maxsize

登录后复制

参数：

maxsize

登录后复制

决定了缓存中最多能存储多少个不同的函数调用结果。

```
maxsize=None
```
登录后复制
(或
0
登录后复制
)：这意味着缓存大小没有限制。所有不同的函数调用结果都会被存储下来。
- 潜在问题：如果你的函数被调用的参数种类非常多，且这些参数组合不会重复出现，那么缓存会无限增长，最终可能导致内存溢出（MemoryError）。这在处理用户输入、日志分析等场景中尤其危险，因为输入的多样性是不可控的。
- 合理配置：只有当你确定函数的输入参数集合是有限且可控的，或者你希望缓存所有结果以获得最大性能提升，并且有足够的内存预算时，才考虑使用
```
maxsize=None
```
  登录后复制
  。例如，缓存一些固定的配置字典或少量枚举值。
```
maxsize
```
登录后复制
为正整数：这是最常见的用法，缓存会根据LRU策略自动淘汰最久未使用的项。
- 潜在问题：如果
```
maxsize
```
  登录后复制
  设置得过小，缓存的命中率会很低，导致大部分时间仍在重新计算，缓存的意义就不大了。同时，频繁的缓存淘汰和插入操作也会带来一定的性能开销。
- 合理配置：
  1. 根据经验值或业务场景预估：如果你的函数通常只处理少数几种核心输入，那么一个较小的
```
maxsize
```
    登录后复制
    可能就足够了。
  2. 监控和调优：
```
lru_cache
```
    登录后复制
    提供了一个
```
cache_info()
```
    登录后复制
    方法，可以返回
```
hits
```
    登录后复制
    、
```
misses
```
    登录后复制
    、
```
maxsize
```
    登录后复制
    和
```
currsize
```
    登录后复制
    等信息。通过观察
```
hits
```
    登录后复制
    和
```
misses
```
    登录后复制
    的比例，你可以判断当前的
```
maxsize
```
    登录后复制
    是否合理。如果
```
misses
```
    登录后复制
    远高于
```
hits
```
    登录后复制
    ，可能就需要增大
```
maxsize
```
    登录后复制
    。
  3. 内存预算：考虑每个缓存项可能占用的内存大小，以及你的系统总共能提供多少内存。
```
maxsize
```
    登录后复制
    应该在保证良好命中率的同时，控制在可接受的内存范围内。

关于

typed

登录后复制

参数：

typed

登录后复制

参数控制缓存是否区分函数调用的参数类型。默认情况下，

typed=False

登录后复制

。

```
typed=False
```
登录后复制
(默认值)：
```
lru_cache
```
登录后复制
会认为
```
f(1)
```
登录后复制
和
```
f(1.0)
```
登录后复制
是同一个调用，因为在Python中，整数
```
1
```
登录后复制
和浮点数
```
1.0
```
登录后复制
在很多上下文下是等价的。
- 潜在问题：如果你的函数逻辑实际上对参数类型敏感，例如，
```
process_data(1)
```
  登录后复制
  和
```
process_data(1.0)
```
  登录后复制
  会产生不同的结果（比如一个处理整数ID，一个处理浮点数精度），那么
```
typed=False
```
  登录后复制
  会导致缓存结果错误。它会返回
```
f(1)
```
  登录后复制
  的结果给
```
f(1.0)
```
  登录后复制
  ，从而引入难以发现的bug。
- 合理配置：当你的函数对参数类型不敏感，或者你明确知道不同类型但值相同的参数会产生相同结果时，保持
```
typed=False
```
  登录后复制
  是合适的，这可以提高缓存命中率。
```
typed=True
```
登录后复制
：
```
lru_cache
```
登录后复制
会严格区分参数的类型。
```
f(1)
```
登录后复制
和
```
f(1.0)
```
登录后复制
会被视为两个不同的调用，分别进行缓存。
- 潜在问题：如果你的函数对参数类型不敏感，但你设置了
```
typed=True
```
  登录后复制
  ，这会导致缓存命中率降低和内存使用增加，因为同一个“逻辑值”可能会被缓存多次，只是类型不同。
- 合理配置：当你的函数行为确实依赖于参数的具体类型时，例如一个函数会根据输入是
```
int
```
  登录后复制
  还是
```
str
```
  登录后复制
  来执行不同的逻辑，那么
```
typed=True
```
  登录后复制
  是必不可少的。它确保了缓存的正确性，避免了因类型差异导致的混淆。