在 __init__ 中用 self.counter += 1 会创建实例属性遮蔽类变量，导致计数不准；应使用 self.__class__.counter += 1 支持继承隔离，配合类锁防多线程竞态，并推荐用 @classmethod 提升可维护性。
为什么在 __init__ 里直接操作类变量会“计数不准”
因为每次实例化都执行 __init__，如果写成 self.counter += 1，实际是在给实例新增一个同名实例属性，遮蔽了类变量——后续再访问 self.counter 拿到的是实例值，不是类值。真正想累加的是类本身的变量，必须显式通过类名或 type(self) 访问。
self.__class__.counter += 1 和 ClassName.counter += 1 哪个更安全
优先用 self.__class__.counter += 1。它支持继承：子类实例化时自动更新子类自己的类变量，而不是父类的。而硬写 ClassName.counter 会把所有子类的计数都塞进父类变量里，失去隔离性。
- 若父类叫
Base，子类叫Child，Child()调用self.__class__.counter→ 更新的是Child.counter - 若写死
Base.counter += 1→ 所有子类实例都往Base.counter上加，Child.counter根本没变 - 注意：类变量需在类定义顶层初始化，如
counter = 0，不能只在__init__里首次赋值
如何避免多线程下计数错乱
类变量是全局共享的，多个线程同时执行 self.__class__.counter += 1 可能导致竞态——读取、+1、写回三步不原子。简单场景可用 threading.Lock，但别锁整个 __init__，只锁计数段：
import threading
class Counter:
counter = 0
_lock = threading.Lock()
def __init__(self):
with self._lock:
self.__class__.counter += 1
- 不用
self.lock（那是实例锁，无效），必须用类级别的_lock - 如果只是调试或单线程脚本，可省略锁；但一旦部署到 Web 或异步环境（如 FastAPI 的并发请求），必须加
- Python 的 GIL 不能保证类变量操作的原子性，这点常被误判
用 @classmethod 分离计数逻辑是否更清晰
是的。把计数行为从 __init__ 拆出来，语义更明确，也方便单独测试或禁用：
class Counter:
counter = 0
def __init__(self):
self.increment_counter()
@classmethod
def increment_counter(cls):
cls.counter += 1
- 测试时可直接调用
Counter.increment_counter()验证逻辑，无需构造实例 - 子类可重写
increment_counter控制计数条件（比如只在满足某字段时才加） - 若某次创建实例不想计数，只需绕过
increment_counter调用，而不是改__init__主体
类变量计数看着简单，但继承、线程、初始化时机这三点一碰就出问题——尤其当代码从脚本迁移到服务后，突然发现计数比实例数少一半，大概率是子类没隔离或锁没加对。
