Python中单下划线前缀（如_method）仅为内部使用约定，不阻止外部访问；双下划线触发名称改写（如_Foo__method）以防子类覆盖，但非真正私有；选择依据是职责边界而非可见性。
Python中单下划线前缀不是真正的私有机制
单下划线前缀（如 _method）在Python中**不阻止外部调用**，它只是开发者之间的约定，表示“这个方法/属性是内部使用的，请勿依赖”。解释器完全允许你访问 _method，IDE也不会报错，运行时更不会抛异常。
常见错误现象：有人以为加了 _ 就像Java的 private 一样安全，结果在子类或外部模块里直接调用了 _helper，后续重构时改名或删掉，导致调用方静默崩溃。
- 它不影响任何运行时行为，仅靠文档和团队自律维持
- PyLint、mypy 等工具可识别并警告对
_xxx的外部访问，但需主动开启检查 - 子类仍能自由继承和覆盖
_method，这和“私有”语义相悖
双下划线前缀会触发名称改写（name mangling）
如果真想增加调用门槛，可用双下划线前缀（__method）。Python会在编译时自动将其重命名为 _ClassName__method，从而避免被子类意外覆盖，也使外部调用变得显眼且易察觉。
使用场景：仅用于**类内部强隔离的辅助逻辑**，比如防止子类无意覆盖关键计算步骤，或明确标记“此处绝不可由外部触碰”。
立即学习“Python免费学习笔记（深入）”；
python-script-generator
下载
快速生成专业的 Python 脚本和应用代码。一键创建完整项目结构，支持CLI、API、爬虫、Bot、Django等多种项目类型，包含完整的项目结构、配置文件、依赖管理、测试、README和文档。
- 名称改写只发生在类定义体内，对实例变量或模块级变量无效
- 仍可通过
obj._ClassName__method()强行调用——它防的是手误，不是恶意绕过 - 若类名是
Foo，则__bar在实例上变为_Foo__bar；若子类叫Bar，其自身的__bar会变成_Bar__bar，互不干扰
class Calculator:
def __init__(self, value):
self.__value = value # 实际存储为 _Calculator__value
<pre class="brush:php;toolbar:false;">def __double(self):
return self.__value * 2 # 调用的是 _Calculator__double
def public_calc(self):
return self.__double() + 10
何时该用单下划线、双下划线，还是@property
选择依据不是“想不想让人看见”，而是“这个东西的职责边界在哪”。很多情况下，真正需要的是接口封装，而不是名字藏匿。
- 对外提供稳定行为，但内部实现可能变 → 用
@property或公共方法包装，把_cache、_validate这类细节藏在内部 - 仅供当前类使用，且不希望子类继承或覆盖 → 用
__method（注意：它不解决“不能调用”，只解决“不该被覆盖”） - 供子类扩展，但提醒使用者“这不是公开API” → 用
_method，并在文档里说明生命周期承诺（如“此方法可能在下个大版本移除”）
性能影响几乎为零，但过度使用双下划线会让调试和单元测试变麻烦——你得记住改写后的名字，或者用 dir(obj) 查看真实属性名。
容易被忽略的关键点：导入时的下划线行为
模块级的单下划线前缀还有另一层含义：from module import * 不会导入以 _ 开头的名称。但这和类内私有化无关，纯属模块命名空间规则。
- 模块里写
_helper = lambda x: x+1，再执行from mymod import *，_helper不会出现 - 但
import mymod; mymod._helper依然有效 - 类里的
_method不受此规则影响——它根本不在模块顶层命名空间中
真正难缠的不是语法限制，而是当多个开发者对“_ 是不是私有”理解不一致时，代码逐渐变成谁都能改、谁都不敢动的状态。比名字更关键的是明确写在文档字符串里的契约。
