Python中__var触发名称改写，__var__是特殊方法/属性；前者仅用于类内避免子类覆盖，后者属保留命名空间，二者均非普通变量用法。
Python中__var和__var__会触发不同机制
下划线数量和位置直接决定Python如何处理这个名称：__var（双前导）触发名称改写（name mangling），__var__（双前导+双后缀）被解释器识别为特殊方法或属性。两者都不是普通变量该用的形式。
常见错误现象：把__cache当成“只是更私有一点的_cache”，结果在子类里访问不到；或者误用__data__，导致和__str__、__len__等冲突，引发不可预期的行为。
-
__var会被自动重命名为_ClassName__var，仅适用于类内部属性，且不建议用于模块级变量 -
__var__是保留命名空间，Python随时可能新增如__match_args__这类新魔术方法，你的__mydata__可能某天就失效或报AttributeError - 哪怕你没定义类，只在模块顶层写
__version__ = "1.0"，也属于约定俗成的保留字段——不是语法错误，但破坏了工具链（比如importlib.metadata会读它）
from module import *会忽略_var但不会忽略__var
单下划线_var在from module import *时被跳过，这是明确的约定；但双下划线__var没有这个保护机制，反而更容易因名称改写导致导入后无法访问。
使用场景举例：你写了一个工具模块，定义了_helper和__internal两个变量，然后在别处用from myutil import *。结果_helper没被导入（符合预期），而__internal因为名称改写变成_myutil__internal，根本不在导入列表里——你以为它“更私有”，其实它彻底消失了。
立即学习“Python免费学习笔记（深入）”；
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 模块级
__var不会被改名，但会被视为“私有”，大多数linter（如pylint）会警告 - 如果真需要模块级私有变量，用
_var即可；__var只应在类中、且有明确继承规避需求时才出现 - 别指望
__var能阻止别人访问——它只是让直接点调用变麻烦，不是安全边界
IDE和静态检查工具对多下划线命名敏感
PyCharm、VS Code + Pylance、mypy 默认把_var标为“非公共”，把__var标为“可能未定义”，把__var__当特殊成员处理。这不是bug，是它们在按PEP 8和CPython实现逻辑做推断。
性能影响虽小，但真实存在：名称改写发生在类定义时，每次加载含__var的类都会多一次字符串拼接和字典键重映射；而__var__相关的反射操作（如getattr(obj, '__str__')）比普通属性访问慢约15%（基准测试数据来自cpython 3.12）。
- mypy对
__var默认报error: Name "xxx" is not defined，除非显式加# type: ignore - Black格式化器不会动
__var__，但会对_var保持原样——这说明工具链已把二者视为不同语义层级 - 如果你用
dir()查对象属性，__var会出现在结果里（改名后），而_var不会——调试时容易误判可见性
真正该用下划线开头的只有三种情况
不是“不能用”，而是“只在特定意图下才该用”。多数人写__cache或_temp时，并没想清楚自己到底要表达什么。
- 模块内临时变量或丢弃值：用单个
_，比如for _ in range(10):或a, _, c = data - 模块级“受保护”变量/函数：用
_var，表示“别依赖我，API可能变”，例如_DEFAULT_TIMEOUT - 类中需避免子类覆盖的属性：用
__var，且必须确认子类确实会定义同名属性，否则纯属画蛇添足
最容易被忽略的一点：下划线开头的变量名一旦进入公共API（比如函数返回值、文档公开的属性），就很难再改——因为下游代码可能已经直接引用了_internal_state，而你没法发一个breaking change去删它。
