如何通过装饰器模式在不修改原有业务逻辑下实现动态的权限校验与日志审计

如何通过装饰器模式在不修改原有业务逻辑下实现动态的权限校验与日志审计

在业务函数里直接嵌入 if not user.has_role("admin") 或者手动调用 logging.info，乍看之下能快速跑通，但长期来看，这无异于埋下技术债。函数签名被污染、逻辑四处重复粘贴、想开关日志还得全局搜索——这根本不是优雅的扩展，而是典型的硬编码陷阱。

Python 中用 @wraps 写权限装饰器，必须处理好上下文提取

权限校验的核心难点，往往不在于“有没有装饰器”，而在于“用户、角色和请求上下文从哪里来”。一个常见的误区是，假设存在一个全局的 current_user 变量，结果在多线程或异步场景下，用户信息就串了。另一个误区是把用户对象硬塞进 *args，导致被装饰函数的签名变得面目全非，兼容性尽失。

• 从标准位置提取是关键：对于Web框架，优先使用 Flask 的 g.user 或 FastAPI 的依赖注入机制；对于CLI工具，可以利用 click.Context；如果必须显式传入，可以设计为 @role_required(user_arg="user") 这样的参数化形式。
• 装饰器内部应保持轻量：不要在装饰器里执行耗时操作，比如查询数据库。正确的做法是，由上层应用准备好完整的 user 对象，再传递给装饰器。
• 异常类型要精准明确：权限拒绝就抛出 PermissionError，参数缺失则用 ValueError。切忌一股脑地捕获 Exception，那会掩盖真正的错误。

日志装饰器必须区分「记录时机」和「是否启用」两个开关

很多日志装饰器的实现，把开关直接写死在定义里，比如 @log_execution(enabled=True)。这就导致无法根据运行环境（开发、测试、生产）动态控制日志行为。更糟糕的设计是，只在 try 块前记录开始时间，一旦函数内部抛出未捕获的异常，结束日志就永远无法触发，留下一条有头无尾的记录。

• 启用开关应交给配置：建议从环境变量或配置文件中读取，例如 os.getenv("ENABLE_LOGGING", "false").lower() == "true"，实现动态开关。
• 记录点必须成对出现：用 time.time() 记录开始时间，并确保无论函数成功返回还是异常退出，都能记录结束日志。失败时，务必通过 exc_info=True 将异常信息传递给 logging.error。
• 敏感信息过滤是底线：对传入的 kwargs 进行白名单过滤，跳过 password、token 等字段。或者，采用统一截断策略，如 repr(arg)[:100]，避免敏感数据泄露。

组合多个装饰器时，顺序决定行为优先级

当 @log_execution 和 @role_required("admin") 叠加使用时，谁先执行？答案是：自上而下。代码 @A @B def f() 等价于 f = A(B(f))。这意味着，权限检查应该发生在日志记录之前。否则，一个未授权的调用也会留下“开始执行”的日志条目，这完全违背了安全审计的初衷。

• 典型的安全装饰顺序是：@role_required → @log_execution → @cache_result。先鉴权，再记录，最后考虑缓存。
• 如果日志需要包含鉴权结果（例如记录“拒绝访问：用户角色=访客”），那么日志装饰器内部就需要集成鉴权逻辑，而不能单纯依赖外部的权限装饰器。
• 务必避免循环依赖：权限装饰器不应反向调用日志函数，日志装饰器也不该去触发权限校验，保持职责单一。

最后，也是最容易被忽略的一点：装饰器返回的 wrapper 函数，必须保留原函数的 __name__、__doc__ 和签名。否则，help() 文档、IDE的智能补全、单元测试中的mock操作都会出现问题。不使用 @wraps(func) 的装饰器，等于给自己埋下了一颗调试时的地雷。