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

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

则是一个相对更“幕后”的工具，它主要用于自定义装饰器时。装饰器本质上是一个函数，它接受一个函数作为参数，并返回一个新的函数（通常是内部定义的wrer函数）。问题在于，这个新的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

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

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

自定义装饰器时，

functools.wraps

登录后复制

登录后复制

登录后复制

是不可或缺的？

functools.wraps

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

wraps

缺席的后果。

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

__name__

（函数名）、

__doc__

（文档字符串）、

__module__

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

__annotations__

（类型提示）、

__qualname__

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

AI写作和改写润色工具

23

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

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

    登录后复制

    登录后复制

    登录后复制

    登录后复制

    是必不可少的。它确保了缓存的正确性，避免了因类型差异导致的混淆。

我的经验是，对于

maxsize

，大多数时候我会从一个较小但合理的数字开始，然后通过

cache_info()

来观察，并根据实际的生产环境数据进行调整。而

typed

参数，我通常会先问自己：这个函数的行为是否会因为参数是

1

还是

1.0

而有所不同？如果会，那就果断设置

typed=True

，否则就保持默认。这是一个关于正确性和效率的权衡，正确性永远是第一位的。

以上就是functools 模块中的 lru_cache 和 wraps的详细内容，更多请关注php中文网其它相关文章！