python无真正私有字段，双下划线触发名称改写（如__data→_class__data）防子类覆盖，非防访问；单下划线仅为约定，无语法限制；应重意图清晰与协作顺畅，而非过度依赖命名机制。
Python里没有真正意义上的私有字段，所谓“私有”只是靠命名约定和名称改写机制来提示和隔离，不是靠访问控制锁住数据。避免这类字段的命名冲突，关键在理解机制、用对规则、不依赖错觉。
双下划线字段：靠名称改写防子类覆盖，不是防访问
以__value开头（且不以__结尾）的字段，比如self.__data，会被Python自动改写为_ClassName__data。这主要是为了防止子类无意中覆盖父类的同名内部字段。
- 改写发生在编译期，类名变了，改写结果就变——class Config里的__cache变成_Config__cache；换成class AppConfig就变成_AppConfig__cache
- 动态添加的__x（比如obj.__new_attr = 1）不会被改写，它就是字面意思的__new_attr
- __init__、__str__这种前后都双下划线的特殊方法，不参与改写
单下划线字段：纯属约定，靠自觉和规范
像self._internal_flag或_helper()，解释器完全不管——它不会改名，也不会报错，IDE标灰、from mod import *默认忽略，仅此而已。
- 适合内部使用但无需防子类干扰的场景，比如缓存、临时状态、辅助方法
- 别指望它阻止别人调用；有人写obj._internal_flag = True，你拦不住，也不该拦
- 和双下划线混用要小心：__x和_x是两个完全独立的字段，容易自己绕晕
模块与包层级：从结构上隔离命名空间
字段冲突常源于组织松散。把相关类放进同一个模块，再用包结构分层，天然形成命名边界。
- 例如models/user.py定义User类，services/auth.py定义AuthService类，各自用__token互不影响
- 导入时用as重命名：如果两个类都有__config，可分别导入为from core import Config as CoreConfig和from ext import Config as ExtConfig
- 模块名本身也要避冲突：别叫json.py或requests.py，否则import json可能导入的是你自己的文件
实际开发中的清醒做法
与其纠结“怎么让字段更私有”，不如聚焦“怎么让意图更清晰、协作更顺畅”。
- 优先用单下划线+文档说明用途，比硬套双下划线更可持续
- 在模块末尾加__all__ = ["PublicClass", "public_func"]，明确哪些是对外接口，其余默认视为内部实现
- 团队统一命名风格：比如所有内部缓存字段统一用_cache_xxx，配置字段用_cfg_xxx，不靠下划线数量，而靠前缀语义
- 用IDE或pylint检查未使用的私有字段，及时清理冗余，比防御命名冲突更重要
