类变量在类定义时立即初始化，而非实例化时；常见陷阱包括依赖未定路径或共享可变对象；应通过打印验证执行顺序，将运行时依赖移至__init__或类方法中。
类变量未被正确初始化，往往不是语法错误，而是执行顺序导致的“看似合理却失效”的逻辑问题。关键在于理解 Python 中类定义、类变量赋值、实例化三者的实际执行时机。
类变量在类定义时就完成赋值
类变量（如 count = 0）的表达式会在类体执行时立即求值，而非等到实例创建或方法调用时。这意味着如果赋值依赖尚未定义的对象、未加载的模块，或依赖运行时状态，就会出错或得到意外值。
常见陷阱示例：
-
错误写法：
class Config: PATH = os.path.join(os.getcwd(), "conf")—— 若脚本工作目录在导入时未确定（如被其他模块 import 触发），PATH 可能指向错误路径； -
错误写法：
class Cache: store = dict() # 看似安全，但若后续有子类重写 __init__ 却忘了调用 super()，可能误用共享字典造成数据污染。
用代码块分段验证执行时机
把类定义拆解为可观察的执行片段，插入 print 或 logging，明确每一步发生时间：
- 在类定义开头加
print("[1] 进入类定义")； - 在类变量赋值语句前后加打印，例如：
print("[2] 开始计算 DEFAULT_TIMEOUT"); DEFAULT_TIMEOUT = time.time() + 300； - 在
__init__开头加print("[3] 实例初始化")； - 在模块顶层加
print("[0] 模块开始加载")。
运行后观察输出顺序，就能确认类变量是否在预期时刻完成初始化——比如发现 “[2]” 出现在 “[0]” 之前，说明它被提前执行了（通常不会，但 import 链复杂时可能）；若 “[2]” 在 “[3]” 之后，则说明该变量根本不是类变量，而是被误写在了方法里。
区分类变量与实例变量的初始化位置
类变量应在 class 语句体中直接赋值；需要延迟或依赖实例状态的，必须移到 __init__ 中作为实例属性。
-
推荐写法（延迟初始化）：
def __init__(self): self._client = None # 先设为 None，再在首次使用时通过 property 或方法懒加载； -
推荐写法（安全类默认值）：用
None或占位对象初始化类变量，把真实构造逻辑放到类方法中，例如：@classmethod def init_store(cls): cls.store = RedisClient(...)，按需显式调用； - 避免在类体中调用可能失败的函数（如数据库连接、文件读取、网络请求），这些应严格推迟到运行时。
借助 ast 或装饰器静态检查潜在风险
对大型项目，可写简单脚本扫描类定义中是否出现高危调用：
- 用
ast.parse解析源码，遍历Assign节点，在ClassDef内部检查右侧是否含Call（函数调用）、Attribute（如os.path.join）等； - 给类加装饰器（如
@safe_class_init），在装饰器中拦截类对象构建过程，检查类字典中是否有非常量初始值，并告警； - 使用
pylint的invalid-class-object或自定义 checker 插件，标记类体中不安全的表达式。
这类检查不能替代运行时验证，但能提前暴露“看起来像常量、实则会执行”的隐患代码。
