Python类私有属性定义指南：双下划线封装详解

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__来实现复杂的控制逻辑时，这往往是一个信号：你的类设计可能需要重新审视和重构了。