Python中如何定义私有属性？通过双下划线实现类成员的封装
Python中双下划线__name真的能阻止外部访问吗？
答案很明确：不能。双下划线触发的是一个叫做“名称改写”（name mangling）的机制，它并非真正的访问控制。Python的设计哲学里，没有强制性的私有成员机制。当你写下__name时，解释器只是悄悄地将它重命名为_ClassName__name。这个设计的初衷，主要是为了避免在复杂的继承体系中，子类意外地覆盖父类的内部属性，而不是为了彻底禁止外部访问。
一个常见的误解是：看到obj.__private访问报错，就以为属性“私有了”。其实，只要你知道改写规则，通过obj._MyClass__private就能直接进行读写操作。
- 当子类也定义了同名的
__field时，父类和子类的字段实际上互不干扰，因为改写后的名字不同。 - 试图用动态方式访问（比如
getattr(obj, '__field')）会失败，必须使用改写后的完整名称。 - 在IDE的提示或者
dir(obj)的输出里，你看到的也是改写后的名字，这有时会让人困惑真正的字段名是什么。
什么时候该用__name而不是_name？
这个选择的关键在于你的意图。只有在明确需要“避免子类命名冲突”的场景下，才考虑使用双下划线。对于日常的封装需求，或者仅仅是想给使用者一个“这是内部实现，不建议直接使用”的提示，单下划线_name是更合适、也更符合Python社区约定的选择。这个约定被广泛支持，例如from module import *语句就会自动忽略以下划线开头的名称。
我们来对比一下具体的使用场景：
立即学习“Python免费学习笔记（深入）”；
- 使用
_name：适用于内部缓存、临时计算结果、或者API尚未稳定但暂时不希望用户直接依赖的字段。 - 使用
__name：适用于父类中定义了关键内部状态（例如__state），并且预期未来子类很可能会定义同名字段，需要严格隔离的场景。 - 不使用下划线：公开的、设计给外部使用的属性。或者，当你希望通过
@property装饰器来提供受控的访问接口时，背后的存储字段通常也不带下划线。
__init__里赋值self.__x = 1后，为什么hasattr(obj, '__x')返回False？
这是因为名称改写发生在代码的编译期，而不是运行时。当你写下self.__x = 1时，Python在编译这个类定义的时候，就已经把它翻译成了self._ClassName__x = 1。所以，对象创建后，其字典里压根就不存在名为__x的属性，自然hasattr会返回False。
可以通过几种方式来验证：
print(obj.__dict__) # 看到的是 '_MyClass__x': 1 print(hasattr(obj, '_MyClass__x')) # True print(hasattr(obj, '__x')) # False
这个特性容易导致几个“坑”：
- 序列化：使用
json.dumps(obj.__dict__)时，不会包含__x，除非你手动处理改写后的名字。 - 数据类库：在使用
dataclasses或pydantic这类库时，双下划线字段默认不会被自动发现为数据字段，需要显式地进行标注。 - 单元测试：在测试中试图使用
mock.patch('mymodule.MyClass.__x')会失败，必须对改写后的名称进行patch。
想真正限制修改，该用@property还是__setattr__？
答案是优先考虑@property配合@xxx.setter。这种方案语义清晰、调试友好，并且支持添加文档字符串。更重要的是，它只影响你指定的特定属性，不会产生副作用。
相比之下，重写__setattr__方法会影响对象所有属性的赋值操作，实现起来非常容易出错。比如，如果忘记调用super().__setattr__(...)，可能会导致连self._x这样的内部属性都无法正确设置。
来看一个推荐的示例：
class BankAccount:
def __init__(self, balance):
self._balance = balance # 单下划线表示“内部使用”
@property
def balance(self):
return self._balance
@balance.setter
def balance(self, value):
if value < 0:
raise ValueError("Balance cannot be negative")
self._balance = value
那么，__setattr__就一无是处吗？也不是。但它的使用场景更复杂。如果你真的需要拦截所有对_xxx这类属性的修改，在__setattr__里判断属性名前缀时，很容易漏掉__dict__、__weakref__等Python内部使用的特殊属性。而且，这种方法通常无法区分对象初始化时的赋值和后续的修改。话说回来，当你开始考虑用__setattr__来实现复杂的控制逻辑时，这往往是一个信号：你的类设计可能需要重新审视和重构了。
