Python中用下划线命名就能实现私有变量吗？

结论先行：在Python中，单纯使用下划线命名并不能真正实现类似C++或Java那样的私有变量。无论是单下划线还是双下划线，Python解释器在底层机制上都没有提供强行的访问隔离与安全锁闭，外部调用者依然可以通过直接或特定的语法路径读取和修改这些属性。Python的面向对象设计奉行“大家都是成年人（We are all consenting adults here）”的哲学，下划线命名的核心意义在于代码组织契约与避免命名冲突，而非绝对的权限防御。

一、单下划线：基于自觉遵守的约定

以单下划线开头的变量（例如 _internal_flag）在Python中被称为“受保护属性约定”。很多初学者误以为给变量前加上下划线就变成了私有属性，但实际上这完全只是规范层面的提示。

根据Python官方编码规范 PEP 8，单下划线代表该属性或方法是类或模块的“内部实现细节”，调用方不应该在外部直接依赖它。然而，解释器根本不会对这种访问进行任何语法检查或阻拦：

class DatabaseConnection:
    def __init__(self, host: str):
        self.host = host
        self._pool_size = 10  # 开发者约定：内部细节，不建议外部直接操作

conn = DatabaseConnection("localhost")
# 外部依然可以直接访问并修改
print(conn._pool_size)  # 输出示例：10
conn._pool_size = 20
print(conn._pool_size)  # 输出示例：20

在模块级别，单下划线具有唯一的语法效应：当其他模块使用 from module import * 导入时，所有以单下划线开头的名称都会被忽略。不过在类内部，单下划线没有任何实质性的访问限制。它是一道“防君子不防小人”的软防线，提醒其他开发者“如果你在外部修改了这个变量，出现任何故障需要自行承担责任”。

二、双下划线：名称改写机制（Name Mangling）

当开发者发现单下划线无法阻止外部访问后，往往会转向双下划线命名（例如 __private_key）。此时如果直接从外部尝试访问，解释器确实会抛出异常，这常常让人产生“已经实现了真正私有变量”的错觉：

class UserAccount:
    def __init__(self, username: str, password_hash: str):
        self.username = username
        self.__password_hash = password_hash  # 以双下划线开头

account = UserAccount("alice", "e10adc3949ba59abbe56e057f20f883e")
try:
    print(account.__password_hash)
except AttributeError as e:
    print("抛出异常：", e)
    # 示例输出：抛出异常： 'UserAccount' object has no attribute '__password_hash'

从表面上看，直接访问 account.__password_hash 失败了。但这里的本质并不是访问控制列表（ACL）拒绝，而是 Python 触发了名称改写（Name Mangling）机制。

当解释器在类定义体中遇到以至少两个下划线开头、且最多以一个下划线结尾的标识符时，会自动在标识符前面加上一个下划线和当前类名，即转换为 _类名__变量名。在上述示例中，变量实际上被改名为了 _UserAccount__password_hash。

我们可以直接在代码中通过改写后的名称进行验证：

# 通过改写后的真实属性名访问
print(account._UserAccount__password_hash)
# 示例输出：e10adc3949ba59abbe56e057f20f883e

# 甚至可以直接进行外部覆写
account._UserAccount__password_hash = "new_secret_hash"
print(account._UserAccount__password_hash)
# 示例输出：new_secret_hash

这清晰地证明了：双下划线并不能提供私有变量的安全保障。那么，Python为什么要引入这种名称改写机制？

它的真实用途是为了避免子类重写父类属性时的命名冲突。在大型面向对象项目中，如果基类定义了一个内部变量 self.__config，派生类如果不清楚基类的内部细节，也很容易在自己的方法中定义一个 self.__config。有了名称改写机制，基类的属性被保存为 _Base__config，派生类的属性被保存为 _Sub__config，二者在对象的字典中和平共处，互不干扰。

三、前后双下划线：系统级魔术方法，严禁私用

有些开发者在编写类时，会随意定义形如 __custom_data__ 的变量，认为前后都加下划线“更高级”或“更私有”。这种做法是完全错误的。

在Python中，形如 __init__、__str__、__len__ 的命名被称为特殊方法（Magic Methods 或 Dunder Methods）。解释器对其不做任何名称改写，它们是公开暴露的系统协议钩子。随意使用前后双下划线自定义变量，不仅无法实现封装，还极易与未来Python新版本中引入的语言级协议产生命名冲突。

四、在Python中如何正确实现属性封装？

既然下划线无法从物理上锁死变量，那么当我们需要对类的属性进行防护、只读保护或数据校验时，该如何做？

Python推荐的工程标准方案是：使用单下划线作为内部存储约定，配合 @property 装饰器提供受控的访问接口。这样既符合Pythonic的语法习惯，又能实现参数合法性检查与只读保护。

class ProductItem:
    def __init__(self, name: str, price: float):
        self.name = name
        self._price = 0.0     # 单下划线：内部存储字段
        self.price = price     # 通过 setter 统一验证

    @property
    def price(self) -> float:
        """只读访问接口（Getter）"""
        return self._price

    @price.setter
    def price(self, value: float) -> None:
        """修改守卫接口（Setter），执行参数合法性校验"""
        if not isinstance(value, (int, float)) or value < 0:
            raise ValueError("商品价格必须为非负数")
        self._price = float(value)

item = ProductItem("机械键盘", 399.0)
print(item.price)  # 正常读取：399.0

try:
    item.price = -50  # 触发非法修改
except ValueError as e:
    print("拦截非法赋值：", e)
    # 示例输出：拦截非法赋值： 商品价格必须为非负数

五、工程决策：何时该用哪种下划线？

在日常开发中，面对不同的业务场景，我们可以遵循以下清晰的决策准则：

• 绝大多数情况使用单下划线 _var：只要属性属于类或模块的内部实现，不希望外部随意依赖，就使用单下划线。这是Python最推崇的习惯做法。
• 仅在避免继承命名冲突时使用双下划线 __var：当你编写基础框架类，且预见会有大量多层继承的子类可能定义同名内部属性时，才考虑使用双下划线触发名称改写。不要仅仅为了“装作私有变量”而滥用双下划线，因为它会给继承调试、单元测试和动态内省带来不必要的复杂性。
• 绝不自定义前后双下划线 __var__：只在实现Python内置魔术方法（如 __eq__、__repr__）时使用。
• 需要属性守卫与数据计算时使用 @property：如果必须在属性读取或写入时加入类型转换、合法性校验或惰性求值，使用 @property 和 @setter。