理解装饰器：从函数到函数增强
装饰器的本质是高阶函数：它接收一个函数对象，并返回一个新的增强函数。在Python中，函数是一等公民，可以像变量一样被赋值、传递和返回。闭包机制允许内部函数访问并记住外部函数的局部变量，这为装饰器保存状态提供了基础。@语法只是语法糖，@decorator 等价于 func = decorator(func)。通过装饰器，我们可以在不侵入原有业务逻辑的前提下，统一注入日志、权限校验或性能监控等横切关注点。例如，定义一个 log_call 装饰器：它接收原函数 func，内部定义 wrapper，在调用 func() 前后打印日志，最后返回 wrapper。当使用 @log_call 标记 say_hello 函数时，实际执行的是 say_hello = log_call(say_hello)。调用 say_hello() 时，会先触发 wrapper 中的前置逻辑，再执行原函数，最后执行后置逻辑。这种设计彻底解耦了核心业务与辅助逻辑，大幅提升了代码的可维护性。
掌握装饰器参数传递：从简单到通用
实际开发中，被装饰的函数往往携带位置参数与关键字参数。若装饰器内部硬编码参数，将导致复用性极差。正确做法是在包装函数中使用 *args 和 **kwargs 接收任意参数，并原样透传给原函数。当装饰器自身也需要接收配置参数时，必须采用三层函数嵌套结构：最外层工厂函数接收配置参数并返回真正的装饰器；中间层接收被装饰函数；最内层 wrapper 负责拦截调用。例如，编写一个带重试次数的装饰器 @retry(times=3)。调用时，Python 首先执行 retry(times=3) 返回 decorator，随后 decorator 接收目标函数并返回 wrapper。在 wrapper 中，通过循环捕获异常并重新执行 func(*args, **kwargs)，可验证参数是否完整传递。运行包含 def fetch_data(url, timeout=5) 的测试代码，终端将输出每次重试的入参快照，证明 *args 与 **kwargs 成功实现了参数无损转发，使装饰器具备真正的通用性。
装饰器实战：日志、计时与权限校验
装饰器在工程实践中常用于处理横切关注点。日志记录场景下，可编写 @log_action 装饰器，在函数执行前后自动记录调用者、参数及返回值，便于审计追踪。性能监控场景推荐使用 @measure_time，内部调用 time.perf_counter() 计算差值并格式化输出耗时，帮助快速定位瓶颈。权限校验则可通过 @check_permission 实现，在包装函数中读取当前会话角色，若未匹配预设权限则直接抛出 PermissionError，拦截非法请求。选择装饰器时应遵循单一职责原则：日志与计时属于无状态增强，可直接使用双层结构；权限校验通常依赖外部配置，适合采用带参数的三层工厂模式。将三者组合应用于同一业务函数时，只需按 @check_permission、@measure_time、@log_action 的顺序叠加，即可在不改动核心代码的前提下，获得完整的可观测性与安全控制能力，运行测试即可直观验证各层拦截效果。
常见坑与最佳实践：让装饰器更可靠
编写装饰器时极易忽略函数元信息的丢失问题。由于包装函数替换了原函数，其 __name__ 和 __doc__ 会被覆盖为 wrapper，导致调试困难与文档生成失败。标准解法是引入 functools.wraps 修饰内部包装函数，自动同步原函数的元数据。多装饰器叠加时需注意执行顺序：语法上自下而上应用，但调用时自上而下执行，错误排序可能导致权限校验在日志记录之后触发。此外，包装函数必须显式返回 func(*args, **kwargs) 的结果，否则原函数的返回值将被丢弃。异常处理方面，若需全局捕获错误，应在 try...except 块中包裹调用逻辑，并在处理完毕后使用 raise 重新抛出，避免掩盖底层堆栈。通过编写单元测试检查 func.__name__、验证返回值类型及异常传播路径，可系统性规避上述陷阱，确保装饰器在生产环境中稳定可靠。
