坚持到第13天终于有底气写一篇真正算进阶的内容了。回头翻我自己列的自学计划day 13 进阶3这行字写在最前面的时候我还不知道要写什么现在回头看看这第三个进阶专题刚好卡在一个特别关键的位置上——前12天把基础语法、函数、模块、异常、文件操作、迭代器和生成器过了一遍代码能跑但总感觉少了点设计感。这第13天要解决的就是让代码从能跑变成好用核心武器是Python里的装饰器和上下文管理器。这篇文章不是教科书式地列知识点而是我真实的学习笔记和实操记录。从闭包这个底层机制说起到装饰器写法的完整演进再落到日志、缓存、重试这几个实际场景最后用上下文管理器补齐资源管理的拼图全程附带我能复现的代码和踩过的坑。适合那些已经把Java基础语法啃完、正往工程化方向走的开发者也适合像我这样靠自学计划稳步推进的人。1. 为什么第三个进阶专题要选装饰器1.1 前12天到底学了什么以及为什么到第13天才碰装饰器我在前12天走的是这样一条路径前3天搞定变量、循环、函数这些语法地基第4天到第6天啃完列表、字典、集合这些核心数据结构第7天开始接触模块和包第8天处理异常第9天和第10天学了文件的读写和序列化第11天和第12天把迭代器、生成器、闭包这些概念理了一遍。这个顺序不是随便排的。装饰器这个东西听名字很唬人拆开来看就是接收函数、返回函数的普通函数。但如果不懂闭包你就理解不了为什么函数可以记住外层的变量如果没写过生成器你就感受不到惰性求值带来的性能红利。这些前置知识没有装饰器只能是死记硬背的语法糖一旦遇到叠加、带参数这种复杂情况就会抓瞎。第13天把装饰器作为进阶3来学正好是知识链条闭合的关键点。此时函数已经玩得比较熟练闭包也大致理解了差的正是把函数当高级对象来操作的那一步。这一步跨过去代码抽象能力会有明显提升。1.2 装饰器解决的痛点用一个真实场景来说假设模拟项目X里有个下单接口我需要在每次调用时打印一句开始执行下单执行完再打印下单完成耗时多少秒。最笨的写法是每个函数体里手写这些打印语句。当时我没多想直接在三个下单相关函数里复制粘贴了六行日志代码。第二天需求变了要在所有日志前加上订单ID。那次改动让我改了十几个函数。这就是装饰器要解决的痛点——横切关注点。日志、鉴权、性能埋点、事务处理这些逻辑和业务逻辑缠在一起导致代码变得臃肿且极难维护。装饰器的思路是把同类逻辑抽出来包装成附加层业务函数还是干业务附加逻辑集中一处管理。谁需要就在谁头上挂一个记号改一处处处生效。1.3 一个12行代码的入门示例先建立感觉先看一个最简单但完整的装饰器长什么样import time def cost_timer(func): def wrapper(*args, **kwargs): start time.time() result func(*args, **kwargs) print(f耗时: {time.time() - start:.4f}秒) return result return wrapper cost_timer def multiply(a, b): time.sleep(0.1) return a * b print(multiply(3, 4))这段代码的执行流程是cost_timer等价于multiply cost_timer(multiply)。multiply这个名字不再直接指向原函数而是指向wrapper。调用multiply(3, 4)时真正被执行的是wrapper(3, 4)wrapper内部先记录时间然后调用原始函数完事打印耗时并返回结果。这里最关键的一点是wrapper通过闭包记住了func。解释器在创建wrapper时把外层函数的func参数保留在了自己的作用域里之后每次调用都能用到。理解了闭包装个器就只是语法层面的小变体。接下来一节拆闭包。2. 闭包机制装饰器的地基2.1 函数是一等公民这决定了装饰器可行很多初学者没有意识到Python里函数和整数、字符串一样是对象。可以被赋值给变量、放进容器、作为参数传给别的函数也可以作为返回值从函数里跑出来。def say_hello(name): return fHello, {name} greet say_hello print(greet(张三)) # Hello, 张三 print(greet.__name__) # say_hellogreet只是一个指向函数对象的引用后面加不加括号决定了是取对象本身还是执行它。装饰器的一切操作都建立在这种函数即对象的基础上没有这个前提任何包装函数的方式都无从谈起。2.2 计数器闭包的完整拆解闭包这个词听起来玄乎用一个计数器例子拆开看就明白了def make_counter(): count 0 def counter(): nonlocal count count 1 return count return counter c1 make_counter() print(c1()) # 1 print(c1()) # 2 print(c1()) # 3普通函数在每次调用结束后局部变量就销毁了。但make_counter返回的counter函数还握着一个对count的引用所以这块内存不会被回收。nonlocal声明告诉Python解释器这个count不是counter内部的局部变量而是来自外层的make_counter作用域。为了加深理解看一眼底层逻辑。counter()内部用nonlocal锁定的是它定义时所在外层栈帧里的count。c1 make_counter()执行后make_counter的栈帧并没有完全销毁而是作为闭包单元被c1携带。每次调用c1()的时候外部函数make_counter框架里的count已经在内存中等待更新。装饰器的wrapper里也是这样它携带的是对原始函数func的引用。这个引用在外界看来是隐藏的但对wrapper来说等于是随身带了一个文件包什么时候打开都行。2.3 作用域规则影响闭包行为一个例子能说明作用域按内置、全局、闭包外层、局部这个方向查找。闭包能访问外层变量但默认只能读不能写。想写就必须加nonlocal。很多人卡在为什么闭包函数里改了外层变量会报错这个问题上。def outer(): x 1 def inner(): x x 1 # UnboundLocalError: local variable x referenced before assignment return x return inner因为Python在编译inner函数时看到了x x 1的赋值动作于是把x标记为inner的局部变量后面的x 1引用的就是尚未被赋值的局部变量自然会报错。解决办法就是加nonlocal x声明。在写装饰器时如果需要在wrapper里记录调用次数等状态信息通常会声明nonlocal或者用一个可变的容器比如字典、列表来规避这一限制。理解了这个规则装饰器里的一切状态管理都清晰了。2.4 闭包常见的误用场景闭包有一个经典坑在循环中创建闭包。funcs [] for i in range(3): def f(): return i funcs.append(f) for f in funcs: print(f()) # 2 2 2期望打印 0 1 2实际全是 2。因为f捕获的是变量i本身而不是当时的值。每次循环i变为新的值所有f引用的都是同一个变量。等循环结束后i是 2所有函数自然都返回 2。修复办法是使用默认参数绑定当前值def f(ii): return i或者改用生成器。这个坑在装饰器里也有变种叠加装饰器时每个装饰器捕获相关参数的方式不同结果就可能出乎意料。后面第6节排坑环节会专门讲。3. 装饰器的写法演进从最笨到最好用3.1 手动版先理解包装这个动作在最朴素的阶段可以完全不用语法纯粹用赋值的方式来包装。def raw_say(name): return fhi {name} def logging_call(func, *args, **kwargs): print(调用前) result func(*args, **kwargs) print(调用后) return result raw_say logging_call(raw_say) print(raw_say(李四))这个写法完成了一个装饰动作把原函数传入一个包装函数返回一个新的可调用对象再把这个新的对象赋值回原名字。这个模式是装饰器的核心实质。但直接这样写有两个毛病每次包装都要手动赋值而且raw_say.__name__已经变成了logging_call函数元信息丢了。手动版帮助我们理解本质装饰器就是函数工厂它接收一个函数加工后吐出另一个函数。明白了这点后面所有的语法糖都只是省打字的方式。3.2 语法糖版符号只是赋值替换用之后原来的手动赋值被语法代替def logging_call(func): def wrapper(*args, **kwargs): print(调用前) result func(*args, **kwargs) print(调用后) return result return wrapper logging_call def raw_say(name): return fhi {name}logging_call放在函数定义正上方等价于在函数定义结束后执行raw_say logging_call(raw_say)。好处是书写简洁、代码位置明确、后面接别的装饰器时读起来像画面上的图层叠加。3.3 元信息丢失与 wraps 修复前面在手动版里提到__name__会变。这在调试、文档生成、依赖函数签名的框架里是致命的。为了让包装后的函数看起来和原函数完全一致标准库提供了functools.wraps。import functools def logging_call(func): functools.wraps(func) def wrapper(*args, **kwargs): print(调用前) result func(*args, **kwargs) print(调用后) return result return wrapperfunctools.wraps本身也是一个装饰器它把原函数的__name__、__doc__、__module__、__qualname__等属性复制到wrapper上并更新wrapper的__wrapped__属性方便反查原函数。写装饰器的时候默认加上它是最佳实践。我一开始天真地以为wraps只是复制属性直到在调试一个用inspect.getfullargspec做参数校验的框架时发现装饰后的函数签名全乱了。加上functools.wraps后签名信息被正确还原这个坑才算彻底填平。3.4 带参数装饰器工厂套工厂有这样一个需求日志装饰器需要传入一个日志级别参数不同的被装饰函数记录不同的级别。简单的logging_call做不到因为语法在任何对象上做不下去了——如果logging_call(levelINFO)Python 会先计算出logging_call(levelINFO)的结果再拿这个结果去处理下面的函数。import functools def log_with(levelINFO): def decorator(func): functools.wraps(func) def wrapper(*args, **kwargs): print(f[{level}] 调用 {func.__name__}) return func(*args, **kwargs) return wrapper return decorator log_with(levelERROR) def bad_thing(): return error happened最外层的log_with是用来接收自定义参数的工厂它返回真正的装饰器decorator。decorator接收函数返回wrapper。整个结构是三层嵌套对应三个不同的职责外层收集参数中层接收函数内层接收运行时参数。这个三层套娃是初学者写装饰器最容易绕晕的地方。我的记忆诀窍是把最外层想成配置器只管拿配置中间的才是装饰器最里面的wrapper才是真正被调用的那个东西。4. 实战应用日志、缓存、重试三种模式4.1 日志装饰器一劳永逸的统一埋点日志是装饰器最经典的应用场景。我在模拟项目X里加工了一个统一日志装饰器统一记录函数名、参数、耗时和异常信息import functools import time import logging logging.basicConfig(levellogging.INFO) def log_call(func): functools.wraps(func) def wrapper(*args, **kwargs): start time.time() try: result func(*args, **kwargs) logging.info(f[{func.__name__}] args{args}, kwargs{kwargs}, 耗时{time.time()-start:.4f}s, 结果{result}) return result except Exception as e: logging.error(f[{func.__name__}] 异常: {e!r}) raise return wrapper这里有一点要注意绝不能在wrapper里把异常吞掉。装饰器只负责记录信息异常应该继续上抛交给上层处理。有些封装不到位的人会在装饰器里捕获后不打日志也不抛异常导致业务层收到None或者直接静默失败排起错来非常痛苦。4.2 缓存装饰器用空间换时间假设某个函数对相同参数会产生相同结果并且计算代价很高那就可以用装饰器做结果缓存。import functools def cached(func): cache {} functools.wraps(func) def wrapper(*args, **kwargs): key (args, tuple(sorted(kwargs.items()))) if key not in cache: cache[key] func(*args, **kwargs) return cache[key] return wrapper cached def expensive_function(x, y): return x ** y这里用字典当缓存以参数组合为键计算结果为值。要求被装饰函数的参数都能被 hash所以不能拿列表做参数得转成元组。这个装饰器用在频繁调用且结果稳定的场景下效果明显比如从数据库读取配置的函数一秒之内被调用几十次。实际生产环境里更建议直接用标准库提供的functools.lru_cache它实现了最近最少使用淘汰策略不会让缓存无限膨胀。自己写的版本更适合学习原理或者应对特殊缓存策略比如需要定期失效时自己控制缓存生命周期。4.3 重试机制给网络请求函数加韧性第三个实用模式是重试装饰器。网络请求偶尔失败不想在业务代码里写一堆重试逻辑用装饰器集中处理干净利落。import functools import time def retry(times3, delay1): def decorator(func): functools.wraps(func) def wrapper(*args, **kwargs): for attempt in range(times): try: return func(*args, **kwargs) except Exception as e: if attempt times - 1: raise time.sleep(delay) return None return wrapper return decorator注意重试的时间间隔最简单的delay1是固定等待更讲究的做法是带随机抖动的delay base * (2 ** attempt) random.uniform(0, 0.5)。这样避免多个请求在重试时扎堆同时发起又引入随机性来错开瞬时故障。4.4 三种模式组合使用装饰器可以叠加retry(times3, delay0.5) log_call def fetch_data(): # 模拟网络请求 return data执行顺序是从下往上的。fetch_data先被log_call处理成带日志的版本然后再被retry包裹。重试的是带日志的版本所以每次重试都会重新记录日志。这个顺序在语义上是合理的先包装内层再包装外层。如果反过来写在上面日志装饰器只是在重试函数的表面包了一层重试内部发生多少次失败都不会记日志容易误判请求次数。设计叠加顺序时要根据实际需求去理解语义。5. 上下文管理器与 with 配套的另一块拼图5.1 with 语句的执行协议装饰器是给函数加外挂上下文管理器是给代码块加边界。核心协议是__enter__和__exit__两个方法class ManagedResource: def __enter__(self): print(进入资源) return self def __exit__(self, exc_type, exc_val, exc_tb): print(退出资源) return Falsewith ManagedResource() as r:在进入代码块前调用__enter__在离开代码块时调用__exit__。__exit__的三个参数保存异常信息返回False表示不拦截异常让它继续抛出去返回True表示吞掉异常阻止它向上传播。日常最常见的应用是文件操作with open(data.txt, r) as f: content f.read()即使读取中途触发异常文件资源也会被正确关闭因为__exit__里已经包含了关闭逻辑。5.2 自实现计时上下文管理器我动手写过一个计时器import time class Timer: def __enter__(self): self.start time.time() return self def __exit__(self, exc_type, exc_val, exc_tb): self.elapsed time.time() - self.start print(f代码块耗时 {self.elapsed:.4f} 秒) return False用法with Timer(): time.sleep(0.3) sum(range(1000))这个比装饰器更灵活的地方在于它能精确测量某个代码片段的耗时而不仅仅是整个函数。在定位性能瓶颈时特别实用。我曾用Timer对比了三种排序方式在小规模数据上的耗时代码结构一目了然。5.3 contextmanager 装饰器用生成器替代类标准库contextlib.contextmanager允许用生成器函数写上下文管理器通常比定义两个方法更简洁from contextlib import contextmanager contextmanager def timer(): start time.time() try: yield finally: elapsed time.time() - start print(f耗时 {elapsed:.4f} 秒)contextmanager把生成器函数包装成一个上下文管理器yield之前的代码在__enter__时执行yield之后的代码在__exit__时执行。finally保证即使代码块抛异常也能执行清理逻辑。这个写法在临时改变环境变量再自动恢复资源临时切换数据库连接这类场景里非常顺手。唯一要注意的是如果yield后面的finally里没有显式处理异常异常会被自动抛出这通常是正确的行为。5.4 资源管理的高级应用场景除了文件、数据库连接、网络连接我还在模拟项目X的做法中用它来管理临时文件目录和线程锁。class FileLock: def __enter__(self): self.lock threading.Lock() self.lock.acquire() return self def __exit__(self, exc_type, exc_val, exc_tb): self.lock.release() return False上下文管理器的价值在于它把获取资源—使用资源—释放资源这个流程标准化了任何健忘的释放逻辑都不会有被遗忘的机会。担心内存泄漏的场景用with包裹比在try/finally里手写更优雅。6. 踩坑实录装饰器叠加、顺序与排查思路6.1 叠加装饰器时执行顺序到底是怎么样的装饰器叠加时的执行顺序是入门以来最困惑我的一个点。测试代码如下def deco_a(func): print(A 包装) def wrapper(): print(A 前置) return func() A return wrapper def deco_b(func): print(B 包装) def wrapper(): print(B 前置) return func() B return wrapper deco_a deco_b def foo(): return foo回到这一节开头我原本以为装饰是从上往下执行但实际打印顺序是B 包装 先出现然后 A 包装。原因是deco_a装饰的是已经经过deco_b包装好的函数所以deco_b优先处理原函数。调用foo()时执行的顺序却反过来先打印 A 前置再打印 B 前置然后执行原函数返回 foo B A。A 在最外层先被调用B 在里层后被执行。这个先包装后执行、外层先入后出的顺序不实际跑一遍很难凭空想明白。6.2 依赖函数签名导致的诡异 bugfunctools.wraps 解决后某次在调试一个模拟项目X中的参数校验组件时发现某装饰器让所有函数都报错参数类型错误。追查后得知该组件通过inspect.signature检查被装饰函数的参数是否有动画结果因为装饰器没加functools.wraps组件的签名检查拿到了wrapper的签名(*args, **kwargs)与调用时传入的真实参数对不上于是校验失败。把functools.wraps加上后签名恢复原样校验逻辑不再丢失。这个教训让我在写所有装饰器时都默认遵守无条件使用functools.wraps。没有例外。6.3 类装饰器什么时候值得使用装饰器不一定是函数也可以是一个类对象。它要求该类的实例是可以被调用的也就是实现__call__方法。class CountCalls: def __init__(self, func): self.func func self.count 0 def __call__(self, *args, **kwargs): self.count 1 print(f调用第 {self.count} 次) return self.func(*args, **kwargs) CountCalls def hello(): return hello类装饰器的优势在于可以通过实例属性保存状态不必依赖闭包里的可变类型。但要注意的是它的实例本身替代了原来的函数如果忘记实现__call__调用时会得到一个类型错误。在使用类装饰器时通常建议同样使用functools.wraps来保留原函数信息尽管类实例本身也可以提供__name__属性。这种写法适合状态比较多、需要把多个数据成员和包装逻辑组织在一起的情景但是过度使用会加重认知负担。我通常只在需要比较多内部状态时才选用类装饰器。6.4 一次完整的排查链路不存在的函数返回值最后一次踩坑是装饰器叠加时返回值被吞掉了。业务代码里有一段rerun_on_failure log_call def fetch_config(): return {key: value}调用fetch_config()总是返回None。先怀疑log_call把它的日志装饰器注释掉问题依旧。再去查rerun_on_failure发现在内部的wrapper循环中漏掉了return语句只在第一次成功时返回了结果重试循环结束后没有最终返回函数落了个隐含的None。排查思路是先将可疑装饰器逐一注释测试缩小范围然后检查被怀疑装饰器的每一处return特别是循环内部是否有提前返回值以及循环结束后是否有兜底返回。装饰器的wrapper必须保证在正常路径下完整返回结果这个省略 return的坑太隐蔽了常常连人查半天。经过这次教训现在我写装饰器时都会直接盯着wrapper的返回值写测试用例而不是只做功能验证。因为装饰器的错误往往是悄悄把结果弄丢这种 bug 靠肉眼看很难发现。想分享的一点额外心得做到第13天我最大的感受是把装饰器和上下文管理器放在一起学是个自然无比的选择。两者虽然实现机制不一样——一个靠函数对象和闭包一个靠协议和 with 语句但它们解决的问题是同一件事把横切逻辑从业务代码里拆出来让每个函数只干一件事。日志、缓存、重试、清理资源这些在以前写起来又烦又容易漏的活儿现在都变成了一个标记符或者一段代码块。如果你也在学建议优先跑通这一篇里所有代码再回头看看前12天写的模拟项目X里哪些地方能改成装饰器或with。哪怕只改造一个函数这一天的内容就真正沉淀进脑子里了。第14天我打算把装饰器和上下文管理器合并成一个小型中间件系统练手到时候有新的体会再继续写。