Python通过双下划线实现“私有”属性和方法，本质是名称混淆而非强制私有，目的是避免子类冲突并提示内部使用，体现“我们都是成年人”的设计哲学。
Python中所谓的“私有”属性和方法，其实并非像其他语言那样提供严格的访问控制。它更多是一种约定和一种巧妙的名称混淆（name mangling）机制，目的是为了避免子类意外覆盖父类的内部实现，以及向开发者表明：这部分内容是类内部使用的，外部最好不要直接干预。从我的经验来看，这体现了Python“我们都是成年人”的哲学，即它相信开发者会遵循约定，而不是通过强制手段来限制。
解决方案
在Python中，要实现“私有”属性或方法，你需要在它们的名称前加上两个下划线（
__）。例如，
__private_attribute或
__private_method()。当Python解释器遇到这种命名方式时，它会自动对其进行名称混淆，将其重命名为
_ClassName__private_attribute或
_ClassName__private_method()。这个
ClassName就是当前类的名称。
这种机制使得从外部直接通过
instance.__private_attribute或
instance.__private_method()访问变得困难，因为这些原始名称在类外部是找不到的。但重要的是，这并非真正的“私有”，如果你知道混淆后的名称，比如
instance._MyClass__private_attribute，你仍然可以访问它们。这更像是一个“请勿触碰”的信号，而不是一道坚不可摧的墙。
class MyClass:
def __init__(self, value):
self.public_attribute = value
self.__private_attribute = f"私有值: {value}" # 双下划线开头的私有属性
def public_method(self):
print(f"这是一个公共方法，可以访问私有属性: {self.__private_attribute}")
self.__private_method() # 内部调用私有方法
def __private_method(self): # 双下划线开头的私有方法
print("这是一个私有方法，通常只在类内部使用。")
# 实例化
obj = MyClass("测试")
# 访问公共属性和方法
print(f"公共属性: {obj.public_attribute}")
obj.public_method()
# 尝试直接访问私有属性和方法（会报错）
try:
print(obj.__private_attribute)
except AttributeError as e:
print(f"尝试直接访问私有属性失败: {e}")
try:
obj.__private_method()
except AttributeError as e:
print(f"尝试直接调用私有方法失败: {e}")
# 通过名称混淆后的名称访问（不推荐，但可行）
print(f"通过混淆名称访问私有属性: {obj._MyClass__private_attribute}")
obj._MyClass__private_method()从上面的例子可以看出，
__private_attribute和
__private_method在类内部可以正常使用，但从外部直接访问就会抛出
AttributeError。而通过
_MyClass__private_attribute这样的方式，则又可以绕过限制。这多少有点意思，不是吗？
立即学习“Python免费学习笔记（深入）”；
为什么Python要采用这种“半私有”的机制？
我个人觉得，Python的这种设计哲学很务实。它认识到，在软件开发中，完全的“私有”有时反而会成为束缚。双下划线的机制，主要有两个核心目的：
首先，避免名称冲突。尤其是在继承体系中，如果子类不小心定义了一个和父类内部实现同名的属性或方法，可能会导致意想不到的bug。通过名称混淆，父类的
__private_method会变成
_ParentClass__private_method，而子类即使也定义了
__private_method，它会被混淆成
_ChildClass__private_method，两者互不干扰。这在构建复杂的库或框架时，对于维护内部一致性至关重要。
其次，明确接口与实现的分离。当一个属性或方法被标记为
__开头时，它向其他开发者传递了一个明确的信号：这是一个内部实现细节，不属于类的公共接口。外部代码应该依赖于公共方法来与对象交互，而不是直接操作这些内部状态。这有助于代码的封装性，让维护者在不破坏外部依赖的情况下，更容易地修改类的内部实现。虽然不是强制性的，但这种约定在团队协作中，能大大提升代码的可读性和可维护性。在我看来，这比那些硬性规定，在实际开发中更具弹性。
除了双下划线，Python还有哪些管理内部状态的约定？
当然有，而且在实际开发中，你可能会发现另一种约定更为常见，那就是单下划线前缀（
_）。
当一个属性或方法以单下划线开头，例如
_internal_attribute或
_internal_method()，这在Python社区中被广泛认为是“受保护的”或“内部使用的”约定。这意味着这些成员虽然可以从外部直接访问，但它们是供类内部或子类使用的，外部代码应该避免直接调用或修改它们。这纯粹是一种君子协定。
class MyOtherClass:
def __init__(self):
self._internal_data = "这是内部数据" # 单下划线约定
self.__private_config = "这是私有配置" # 双下划线混淆
def _process_data(self): # 单下划线约定方法
print(f"处理内部数据: {self._internal_data}")
def get_config(self):
return self.__private_config
# 实例化
another_obj = MyOtherClass()
# 访问单下划线成员（可以访问，但不推荐）
print(f"直接访问内部数据: {another_obj._internal_data}")
another_obj._process_data()
# 访问双下划线成员（需要通过公共方法或混淆名称）
print(f"通过公共方法获取私有配置: {another_obj.get_config()}")对比
_和
__：
-
_
(单下划线)：这是一个弱私有约定。它不会触发名称混淆，仅仅是告诉开发者“请勿直接访问”。IDE通常会对此发出警告。它适用于那些你希望子类能够访问，但外部使用者不应该直接碰触的成员。 -
__
(双下划线)：这是一个强私有约定，通过名称混淆来“伪装”成员名称，使其在外部更难直接访问。主要目的是为了避免子类中的名称冲突，并更强烈地表明这是类的内部实现细节。
在很多情况下，我发现单下划线的约定已经足够。它提供了一定的灵活性，又清晰地表达了意图。双下划线更多地用于一些核心库或者框架中，以确保其内部逻辑的健壮性，防止意外的覆盖。
如何在不暴露内部细节的情况下提供属性访问？
这是一个很实际的问题。很多时候，我们希望外部能够读取（甚至写入）某个属性，但又不希望它直接操作我们类的内部数据结构，或者希望在读写时能做一些额外的逻辑处理。Python的属性（Properties）机制就是为此而生，它通过
@property装饰器提供了一种优雅的解决方案。
属性机制允许你像访问普通属性一样访问一个方法，但在背后，它可以执行任意的代码。这使得你可以在不改变外部接口的情况下，将一个简单的属性访问转换为方法调用。
class Temperature:
def __init__(self, celsius):
self._celsius = celsius # 内部存储使用单下划线约定
@property
def celsius(self):
"""获取摄氏温度"""
print("--- 正在获取摄氏温度 ---")
return self._celsius
@celsius.setter
def celsius(self, value):
"""设置摄氏温度，并进行有效性检查"""
if not isinstance(value, (int, float)):
raise ValueError("温度值必须是数字！")
if value < -273.15: # 绝对零度
raise ValueError("温度不能低于绝对零度！")
print(f"--- 正在设置摄氏温度为 {value} ---")
self._celsius = value
@property
def fahrenheit(self):
"""根据摄氏温度计算华氏温度"""
print("--- 正在计算华氏温度 ---")
return (self.celsius * 9/5) + 32
# 实例化
temp = Temperature(25)
# 像访问属性一样获取值
print(f"当前摄氏温度: {temp.celsius}°C")
print(f"当前华氏温度: {temp.fahrenheit}°F")
# 像设置属性一样设置值
temp.celsius = 30
print(f"更新后摄氏温度: {temp.celsius}°C")
# 尝试设置无效值
try:
temp.celsius = "二十"
except ValueError as e:
print(f"设置温度失败: {e}")
try:
temp.celsius = -300
except ValueError as e:
print(f"设置温度失败: {e}")在这个
Temperature类中，
_celsius是一个内部存储温度的私有属性（通过单下划线约定）。而
celsius和
fahrenheit则是公共属性，但它们的背后实际上是方法。
@property装饰器将
celsius方法变成了可读属性，而
@celsius.setter则允许它被赋值，并在赋值时执行我们定义的校验逻辑。
fahrenheit属性更是完全由计算得来，没有对应的内部存储，却提供了外部友好的访问接口。
这在我看来，是Python在封装和提供友好接口之间找到的一个绝佳平衡点。它避免了直接暴露内部数据，同时又提供了灵活且可控的属性访问方式，这比简单地把所有东西都标记为“私有”要实用得多。这种方式让我能够更好地控制对象的行为，而不是仅仅隐藏数据。
