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 timefrom functools import lru_cache@lru_cache(maxsize=128) # 默认缓存128个最近的调用def expensive_calculation(a, b): print(f"Calculating {a} + {b}...") time.sleep(1) # 模拟耗时操作 return a + bprint(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 wrapsdef 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_decoratordef add(x, y): """This function adds two numbers.""" return x + yprint(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
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
是不可或缺的？
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
lru_cache
的
maxsize
和
typed
参数应如何合理配置以避免潜在问题？
lru_cache
确实很强大，但它的
maxsize
和
typed
参数配置不当，也可能带来一些意想不到的问题。这就像一把双刃剑，用得好能事半功倍，用不好则可能适得其反。
关于
maxsize
参数：
maxsize
决定了缓存中最多能存储多少个不同的函数调用结果。
maxsize=None
(或
0
)：这意味着缓存大小没有限制。所有不同的函数调用结果都会被存储下来。
潜在问题：如果你的函数被调用的参数种类非常多，且这些参数组合不会重复出现，那么缓存会无限增长，最终可能导致内存溢出（MemoryError）。这在处理用户输入、日志分析等场景中尤其危险，因为输入的多样性是不可控的。合理配置：只有当你确定函数的输入参数集合是有限且可控的，或者你希望缓存所有结果以获得最大性能提升，并且有足够的内存预算时，才考虑使用
maxsize=None
。例如，缓存一些固定的配置字典或少量枚举值。
maxsize
为正整数：这是最常见的用法，缓存会根据LRU策略自动淘汰最久未使用的项。
潜在问题：如果
maxsize
设置得过小，缓存的命中率会很低，导致大部分时间仍在重新计算，缓存的意义就不大了。同时，频繁的缓存淘汰和插入操作也会带来一定的性能开销。合理配置：根据经验值或业务场景预估：如果你的函数通常只处理少数几种核心输入，那么一个较小的
maxsize
可能就足够了。监控和调优：
lru_cache
提供了一个
cache_info()
方法，可以返回
hits
、
misses
、
maxsize
和
currsize
等信息。通过观察
hits
和
misses
的比例，你可以判断当前的
maxsize
是否合理。如果
misses
远高于
hits
，可能就需要增大
maxsize
。内存预算：考虑每个缓存项可能占用的内存大小，以及你的系统总共能提供多少内存。
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的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1370102.html
微信扫一扫 
支付宝扫一扫 
