单下划线与双下划线的区别：_var、__var、__var__

答案：Python中下划线用于表达变量或方法的访问意图：单下划线前缀表示内部使用约定，双下划线前缀触发名称修饰以避免继承冲突，双下划线包围的为特殊方法，用于实现语言内置行为，不应随意自定义。

在Python中，变量或方法名前后的下划线并非简单的装饰，它们承载着特定的语义和行为。简单来说，单下划线

_var

是一种弱私有约定，告诉我们这是内部使用的；双下划线

__var

触发了名称修饰（name mangling），旨在避免子类意外覆盖；而前后都有双下划线

__var__

则保留给Python的特殊“魔法”方法。

我一直觉得，理解这些下划线不仅仅是语法层面的事，它更是深入理解Python设计哲学，尤其是关于“约定优于配置”和“明确优于隐含”这两个原则的关键。

当我们看到

_var

，这通常是我在编写模块或类时，希望告诉其他开发者，这个变量或方法主要是供内部使用的。它不是真正意义上的私有，你依然可以直接访问它，但这样做可能会打破我预设的内部逻辑，所以最好避免。这更像是一种绅士协定，一种代码层面的“请勿打扰”标识。比如，我可能会有一个

_helper_function

来处理一些内部数据，外部调用者其实不需要关心它的存在。

而

__var

，也就是双前导下划线，就稍微强硬一些了。这不是为了实现真正的私有化——Python并没有C++或Java那种严格的私有成员概念——而是为了在继承体系中提供一种保护。当我在一个类中定义

__private_data

时，Python解释器会自动将其名称修改为

_ClassName__private_data

。这样一来，即使子类也定义了一个

__private_data

，它们也不会相互冲突。这在构建复杂的继承结构时非常有用，可以有效避免子类无意间覆盖父类的私有属性，从而引发难以追踪的bug。我个人在设计基类时，如果某个属性或方法确实不希望被子类直接访问或覆盖，就会考虑使用它。

至于

__var__

，这完全是另一回事了。这些是Python的“魔法方法”或“dunder methods”（double underscore methods）。它们是Python语言内部机制的一部分，用于实现运算符重载、迭代器协议、上下文管理等高级功能。例如，

__init__

用于构造对象，

__str__

定义对象的字符串表示，

__add__

定义加法行为。我们不应该随意创建自己的

__my_custom_dunder__

方法，因为这些名称是Python保留的，未来可能会被语言本身使用，导致冲突。它们是Python的“幕后英雄”，赋予了对象丰富的行为。

何时选择单下划线

_var

，何时考虑双下划线

__var

？

在我看来，选择

_var

还是

__var

，核心在于你希望传达的“私有性”强度以及对继承行为的预期。

_var

是我最常用的内部约定。它传达的是一种“意图”，而非“强制”。当我在一个模块里写

_config_loader

或在一个类里写

_internal_cache

时，我其实是在说：“嘿，这个东西是为我这个模块或类内部逻辑服务的，如果你从外部直接访问它，后果自负哦，因为我可能随时会修改它的内部实现而不通知你。”它保持了代码的灵活性，也给了开发者足够的信任。我个人偏爱这种方式，因为它更符合Python的“我们都是成年人”哲学，鼓励合作而非严格限制。它更像是给同事的一个温馨提示。

而

__var

则是一个更强烈的信号，尤其是在类继承的场景下。设想你正在构建一个大型框架，其中包含许多基类，你希望确保这些基类的某些内部状态或方法不会被子类无意中修改或覆盖。例如，一个

__state_machine_lock

属性，你可能不希望子类轻易地访问或更改它，因为这可能会破坏状态机的完整性。在这种情况下，

__var

的名称修饰机制就派上用场了。它通过改变属性名称，使得子类即使定义了同名属性，也不会与父类的

__state_machine_lock

发生冲突。当然，这并不是说它就完全无法访问了，你仍然可以通过

_ClassName__var

的形式来访问它，但这已经是一个明确的“我知道我在做什么”的信号了。所以，我的经验是，当你需要在一个复杂的继承体系中，为基类的内部实现提供更强的保护时，

__var

会是一个更合适的选择。

深入理解

__var__

魔法方法的真正用途与边界

__var__

，这些“dunder methods”，是Python对象模型的核心组成部分。它们不是用来定义你自己的“私有”变量，而是用来与Python语言本身进行交互的。当我想到

__init__

，我想到的是对象的诞生；当我想到

__str__

或

__repr__

，我想到的是对象如何向人类或开发者展示自己；当我想到

__add__

或

__len__

，我想到的是如何让我的自定义对象像内置类型一样自然地进行运算或获取长度。

这些方法的存在，使得Python拥有了强大的多态性（Polymorphism）和内省（Introspection）能力。它们允许我们定义自定义对象的行为，让它们能够响应各种内置操作符和函数。比如，如果你想让你的自定义类支持

len()

函数，你就需要实现

__len__

方法。如果你想让你的对象能够像字典一样通过

[]

访问，你需要实现

__getitem__

和

__setitem__

。

所以，这些方法是Python提供给我们的“钩子”（hooks），通过它们，我们可以将自定义逻辑融入到语言的核心机制中。但正因为它们如此强大和核心，我们必须非常谨慎地使用它们。不应该随意发明自己的

__my_method__

，因为这些命名空间是Python语言保留的。未来Python版本可能会引入新的魔法方法，如果你使用了相同的名称，就可能导致意想不到的冲突和行为。它们是Python语言的“内部API”，我们应该尊重它们的用途，并只在需要自定义特定语言行为时才去实现它们。

避免常见的误解：Python中真正的“私有”与封装

很多人初学Python时，会试图用

__var

来实现像Java或C++那样的“私有”成员。这其实是一个常见的误解。Python的设计哲学是“我们都是成年人”，它更倾向于通过约定而非强制来管理访问权限。

__var

提供的名称修饰，其主要目的并非是实现真正的私有性，而是为了解决继承中的命名冲突问题。它只是让外部访问变得“不那么直接”，但并没有阻止你访问。例如，如果你有一个类

MyClass

里面有

__secret

，你仍然可以通过

_MyClass__secret

来访问它。这表明，Python并没有提供一个绝对的机制来阻止你访问任何东西，它只是让某些访问变得不那么“显而易见”或“推荐”。

真正的封装，在我看来，更多的是一种设计原则，而非单纯的语法特性。它关乎于你如何设计你的接口，如何隐藏你的实现细节，以及如何通过清晰的文档和约定来引导使用者。即使是使用

_var

，如果我能清楚地定义我的公共接口，并明确指出哪些是内部实现，那么我的代码就实现了良好的封装。

有时，我甚至会直接使用普通变量，但通过良好的命名（比如

cache_data

而非

_cache_data

）和文档来表明它的用途和预期行为。当一个属性确实需要更强的保护，或者它是一个复杂的内部状态，并且我担心子类会不小心破坏它时，我才会考虑

__var

。但即便如此，我也清楚这并非“私有”，而是一种“名称保护”机制。理解这一点，对于写出地道且符合Python哲学的代码至关重要。