Python私有变量命名规则解析

Python中的“私有变量”其实是一种基于命名约定和静态名称修饰的弱约束机制，并非真正的访问控制：单下划线（_var）仅提示“受保护”，双下划线开头且非结尾（__var）会在类定义时被自动重写为_A__var形式，而双下划线包裹（__var__）则是完全不修饰的特殊方法；这种修饰是编译期一次性完成的、与运行时无关的语法转换，既无法阻止外部访问（通过修饰后名称可直接读写），也不能防止误覆盖或继承冲突，本质上只为防范无心之失而非恶意访问——理解其原理，才能避开调试陷阱、避免在多重继承和框架扩展中踩坑。

Python私有变量根本不是真正的私有

Python没有强制访问控制，所谓“私有变量”只是靠命名约定和名称修饰（name mangling）实现的弱约束。下划线开头的变量（如 _var 或 __var）不会被解释器阻止访问，只是向其他开发者发出“请勿直接使用”的信号。

真正触发名称修饰的是双下划线前缀且**不以双下划线结尾**的标识符，例如 __value；而 __value__ 是特殊方法名，完全不参与修饰。

• _var：单下划线 → 约定为“受保护”，导入时不会被 from module import * 包含，但可自由访问
• __var：双下划线开头、非结尾 → 触发名称修饰，变成 _ClassName__var
• __var__：双下划线开头+结尾 → 魔术方法，不修饰，也不建议自定义

名称修饰发生在类定义时，不是运行时动态计算

Python在类体执行完毕后，扫描所有形如 __xxx 的名字，将它们重写为 _ClassName__xxx。这个过程是静态的、一次性的，与实例无关，也不检查父类或同名变量是否已存在。

这意味着：如果两个父类都有 __x，子类继承后会得到 _ParentA__x 和 _ParentB__x 两个独立属性，不会冲突——但也容易让人误以为它们是同一个东西。

示例：

class A:
    def __init__(self):
        self.__x = 1
<p>class B(A):
def <strong>init</strong>(self):
super().<strong>init</strong>()
self.__x = 2  # 这个会被修饰为 _B__x</p><p>b = B()
print(b._A__x)  # ✅ 输出 1
print(b._B<strong>x)  # ✅ 输出 2
print(b.</strong>x)    # ❌ AttributeError: 'B' object has no attribute '__x'
</p>

名称修饰只作用于类定义中出现的 __xxx，不作用于字符串拼接或 getattr

修饰只发生在语法解析阶段，对运行时构造的字符串无效。你无法靠拼出 "_A__x" 来“绕过”私有，但反而可以靠它“强行访问”——这恰恰说明它不是安全机制。

• 直接写 obj.__x 会失败（找不到），但写 obj._A__x 就能读到
• getattr(obj, "__x") 失败；getattr(obj, "_A__x") 成功
• setattr(obj, "__x", 99) 会新建一个名为 __x 的普通属性，和 _A__x 无关

所以它不防君子，更不防小人，只防手滑误用。

多重继承下名称修饰可能造成意外覆盖或隐藏

当多个父类定义同名双下划线变量时，子类初始化顺序（MRO）不会影响名称修饰结果，但可能掩盖你预期的行为。尤其在调用 super().__init__() 时，若父类的 __x 被子类自己的 __x 修饰名覆盖，逻辑就断了。

常见陷阱：

• 子类重写了父类的 __init__，但忘了调用 super().__init__() → 父类的 _Parent__x 根本没被设置
• 父类 A 和 B 都有 __helper，子类 C 同时继承二者 → C 实例里同时存在 _A__helper 和 _B__helper，但方法里若只写 self.__helper，它只会绑定到当前类（C）修饰后的名字，和父类的毫无关系
• 用 __slots__ = ["__x"] 时，实际生效的是 __slots__ = ["_ClassName__x"]，写错就会报错

名称修饰让代码更难调试，尤其在大型继承链或框架扩展中——你看到的变量名和实际存储的名字从来就不一样。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~