写在前面

模块二函数式编程系列写完，今天开始模块三面向对象进阶。第一篇讲一个看起来很基础、但几乎人人都踩过的坑：类变量和实例变量分不清楚，特别是用可变类型当类变量时本意是“每个实例一份独立数据”。结果却是所有实例共享同一份——这跟 Day01 讲的可变默认参数陷阱其实是同一类问题的两种变体。

：两种属性。两种归属

使用者痛点：很多同学在调试代码时发现，两个看似独立的对象居然互相影响，却找不到根本原因。

• 类变量直接写在类体内、__init__ 之外的属性。归类本身所有，所有实例共享同一份数据。话说回来，
• 实例变量在 __init__里通过 self.attr = … 赋值创建的属性。归每个实例自己所有，互不干扰。

class Employee:
company = "ByteDance" # 类变量：所有 Employee 实例共享
def __init__:
self.name = name # 实例变量：每个实例独立一份

二、为什么：属性查找顺序决定了共享关系

使用者痛点：遇到「某个对象的属性莫名其妙被别的对象改了」时不知道该去哪里追踪根源。

instance.attr 的查找顺序很明确：先查实例自己的 __dict__没有再沿着类的 MRO 往上查找类变量。都没找到才抛 AttributeError. 这个顺序解释了类变量“共享”的本质——它只在类的 __dict__`里存了一份，所有没有同名实例变量的对象都会读取到这同一份。

类变量存在的意义很直接：给所有实例共享配置、常量、计数器这类“不需要每个实例各存一份” 的数据，省内存也表达了语义上的“这是类级别的东西”。问题出在可变类型上：如果把 list/dict) 当作类变量。又用原地修改方式操作它（比如 self.items.append)，并不会触发“实例遮蔽”的赋值分支，所有实例修改的其实是同一个底层对象——这正是很多“线上事故”的起点。

flowchart LR
A --> B{实例字典里
有该属性吗}
B -- 有 --> C
B -- 没有 --> D
D --> E
D --> F

三、怎么用

共享与遮蔽的观点是。修改类变量 vs 修改实例变量

使用者痛点：误以为给某个对象赋值会全局生效，却导致意外的数据覆盖。

e1 = Employee
e2 = Employee
print # ByteDance ByteDance
# 修改类变量本身
Employee.company = "TikTok"
print # TikTok TikTok —— 两个实例都变了
# 给 e1 创建同名实例变量
e1.company = "Alice's own"
print # {'name': 'Alice'。'company': "Alice's own"}
print # Alice's own TikTok —— e1 有了自己的 company，e2 仍读类变量
print # TikTok —— 类变量本身没被 e1 那行改动

instance.attr = value 永远只会操作实例自己的 `__dict__`**，绝不会修改类变量——这也是为什么它叫“遮蔽”而不是“修改”。想改动真正的类级别数据，需要通过 ClassName.attr = value.

至于事故现场。可变类变量被当成“每个实例独立”来用

使用者痛点："购物车竟然跨使用者共用了商品列表！" 这种 bug 常常让产品经理抓狂。

class ShoppingCart:
items = # 本意是给每个购物车一个空列表；实际是所有购物车共享同一个 list 对象
def add:
self.items.append # 原地修改，不是赋值，不会创建实例变量
cart1 = ShoppingCart
cart2 = ShoppingCart
cart1.add
print # —— cart2 什么都没做，却多了个苹果

The culprit is line self.items.append: it mutates shared list in place. Because re is no assignment to self.items。attribute‑lookup chain never creates a shadowing entry in instance’s `__dict__`.

The fix is straightforward – create a fresh list for each instance inside `__init__`:

class ShoppingCart:
def __init__:
self.items = # 每个实例拥有自己的列表
def add:
self.items.append

计数器场景的观点是，`self.count +=…` 为何会废掉计数

User Pain Point:"员工数量明明应该递增。却总是停在 0"，让业务监控报错。

class Employee:
count = 0 # 类级别计数器
def __init__:
self.name = name
self.count += 1 # 错误写法！等价于 self.count = self.count + 1
# → 在此行后每个实例都有自己的 `count` 实例属性，与类计数器脱钩
e1 = Employee
e2 = Employee
print # 0 —— 类计数器根本没有被更新
print # 1 1 —— 看似正常。但已经不是同一个计数器了

The expression `self.count += 1` works in two steps:

• LHS read: Python looks up `self.count` → finds **class** variable .
• LHS write: Assignment creates a **new instance attribute** named `count` with value = 1.

This shadows original class variable for that particular instance. Subsequent “+=” operations only affect shadowed instance attribute.

The correct way is to modify class variable explicitly:

class Employee:
count = 0
def __init__:
self.name = name
Employee.count += 1 # 明确操作的是类级别计数器


print # 2


python
print # Only contains instance attributes
print.__dict__) # Contains class attributes
 

If an attribute appears only in type.__dict__,it’s a class variable;if it’s in instance.__dict__,it’s an instance variable.

四、面试追问 

先检查 instance.__dict__;若未命中则沿 MRO 向上搜索其所属 Class 的 __dict__;若仍未找到则抛 AttributeError. 而 instance.attr = value 始终只写入当前对象的 __dict__,不会改动任何父层级中的同名属性。


因为原地修改不涉及对 self.attr 的赋值动作，所以不会触发 “为该对象创建新条目” 的分支。所有对象仍然指向同一个底层可变对象，从而导致跨实例的数据污染。这正是 “可变默认参数” 陷阱在 OOP 场景下的延伸。

读取阶段使用的是 Class Variable；写入阶段却在当前 Instance 的 __dict__ 中新建同名属性，从此脱钩。正确做法是显式使用 Class 名称进行累加，例如 Employee.count += 1.


检查 instance.__dict__和 type.__dict__。若两者均无，则继续沿 MRO 向上查父类。

下一篇预告 

Dаy12 将讲解 `` __new`` vs `` __init``——对象创建实际为两个阶段。`` __new``负责真正“造出”这个对象，而 `` __init``只负责初始化。这一区别在单例模式、不可变对象等高级场景里尤为关键。