装饰器读取debug状态应于运行时动态判断，优先用os.getenv("DEBUG")解析，配合functools.wraps保留函数签名；类装饰器易在初始化阶段固化环境值，导致行为异常。
装饰器里怎么读取 debug 状态
关键不是“写个开关”，而是让装饰器能感知运行时环境。最直接的方式是检查 __debug__（Python 解释器内置标志，python -O 下为 False），或读取环境变量如 DEBUG。不建议硬编码布尔值，否则每次改逻辑都要动装饰器本身。
实操建议：
- 优先用
os.getenv("DEBUG", "").lower() in ("1", "true", "on")，和 Flask/Django 等主流框架行为一致 - 若项目已统一用
settings.DEBUG，就直接引用它，避免多源头判断 - 不要在装饰器定义时就读取——必须放到被包装函数执行时再判断，否则模块导入阶段就固化了结果
@debug_only 装饰器的正确写法
核心是“返回原函数”还是“返回包装函数”，取决于当前是否满足 debug 条件。不能只靠 if DEBUG: ... else: return func，因为那样会丢失原函数签名和元信息。
实操建议：
- 用
functools.wraps(func)包裹包装函数，确保help()、inspect.signature()正常工作 - 条件不满足时，直接
return func，而不是调用func(*args, **kwargs)—— 否则会绕过所有装饰器链（比如你后面还套了个@cache） - 示例片段：
import functools
import os
def debug_only(func):
DEBUG = os.getenv("DEBUG", "").lower() in ("1", "true", "on")
if not DEBUG:
return func
@functools.wraps(func)
def wrapper(*args, **kwargs):
print(f"[DEBUG] Calling {func.__name__}")
return func(*args, **kwargs)
return wrapper
为什么用类装饰器反而容易出错
类装饰器看似结构清晰，但容易在 __init__ 阶段就提前读取 DEBUG，导致后续环境变量变化后装饰器行为不更新；或者忘记在 __call__ 中透传 *args, **kwargs，引发参数错误。
常见错误现象：
-
TypeError: __call__() takes 1 positional argument but 2 were given：没写def __call__(self, *args, **kwargs) - 装饰器在测试环境生效、生产环境也生效：因为
__init__里读了os.getenv，之后值就固定了 - 被装饰函数的
__name__变成"DebugOnly"：没实现__name__ = func.__name__或没用functools.update_wrapper
多个装饰器叠加时 debug 控制的优先级
Python 装饰器是从下往上执行的，所以 @debug_only 放在最外层（即写在最后一行）才能控制整个调用链。如果它被包在 @lru_cache 里面，那缓存逻辑永远先跑，debug 日志根本不会触发。
使用场景提醒：
- 想只对某几个函数开 debug 日志？把
@debug_only单独加在它们上面 - 想全局关闭所有 debug 行为？改环境变量比一个个删装饰器快得多
- 某些函数需要“即使非 debug 模式也要记录关键错误”，那就别用
@debug_only，改用logging.getLogger().debug(...)，由日志级别控制
真正麻烦的是跨进程或子解释器场景——os.getenv 在 fork 后可能不同步，这时候得靠配置中心或显式传参，而不是依赖装饰器自动推断。
