小泉水不管你是从Java、C++转过来，还是Python入门后就直奔面向对象，第一个让你停下来犹豫的概念八成是封装。而谈到封装，私有属性、私有方法和@property这三个词几乎是绕不过去的一道坎。我第一次用Python写面向对象程序的时候，第一反应是：这封装是不是有点“假”？明明写了个__username，结果换一个名字照样能访问，那私有还有什么意义？后来在项目里摸爬滚打多了才明白，Python的私有从来不是用来防“黑客”的，而是用来约束团队协作和代码维护的一纸协议。今天就把这块彻底聊透，从私有属性、私有方法到@property的优雅访问，一次理清它们各自解决什么问题、什么时候用、怎么用才不会踩坑。
很多同学在网上找“python免费源码大全”，下载了一份号称“企业级”的项目，打开一看却不知道从哪儿下手，原因往往就是封装做得不好——所有状态全裸奔，内部逻辑散落在各层调用里。反过来，封装做得好的代码，外部只需要盯住几个入口，其他全是黑盒，阅读成本和维护成本都低得多。这篇文章写的，就是帮助你从“能写出类”升级到“能把类设计得让别人用得舒服、改得安心”的那个阶段。
1. 封装到底在“封”什么：动手之前要看清的问题
很多教程上来就给结论：封装就是把属性设为私有，然后提供公有方法访问。这话没错，但没说到根子上。我觉得学封装之前，得先想清楚一个问题：我们到底在防谁？
1.1 状态失控带来的连锁灾难
如果你写过一个余额可以随意被改成负数的银行账户类，你大概就能理解封装的第一层价值。假设现在有这样一个类：
python复制class BankAccount:
def __init__(self, owner, balance):
self.owner = owner
self.balance = balance
acc = BankAccount("张三", 10000)
acc.balance = -100000 # 没有任何东西阻止这行代码
balance被直接改成-100000，转入、转出、利息计算全乱套。更要命的是，这个问题在代码审查里非常难被发现，因为acc.balance = -100000这行代码看起来太正常了，和给普通变量赋值没什么区别。一旦业务逻辑复杂起来，你根本不知道是谁在什么时间点改了这个状态。
我自己在项目里就碰到过类似的情况：订单的状态字段被外部直接改成了“已关闭”，但支付流程、库存释放、通知回调这些真正的业务逻辑压根没走，结果后台数据对不上，排查了两天才发现是有个同事在某个接口里顺手写了order.status = "closed"。这就是状态不设防的代价。
1.2 封装的三个层次：状态保护、接口稳定、变更隔离
如果把封装拆开来看，我认为核心价值有三个层次。
第一层是状态保护。内部数据不能因为外部误操作而进入非法状态。这一层依赖的是我们对属性访问的控制，比如在赋值前做校验、做类型检查、做取值范围检查。
第二层是接口稳定。对外暴露的方法和属性是稳定的“合同”，内部实现细节可以随时换。今天列表存储，明天换数据库，只要接口不变，调用方就无感知。很多同学搜“接口封装”，本质就是干这个事——把一堆底层细节藏在稳定的接口后面。
第三层是变更隔离。内部私有方法改了名字、拆了逻辑、重构了实现，不影响任何外部调用。这个价值在项目迭代后期才会真正显现出来，前期代码量小的时候完全体会不到，等代码上万行，你就知道变更隔离有多重要了。
1.3 Python语境下的“私有”到底是什么意思
这里必须说清楚一个观念：Python里的私有，和Java、C++里的private完全是两回事。
Java的private是编译器强制执行的，你写了private String name;，在类外面就是访问不了，想都别想。Python则不同，它没有访问控制关键字，私有的实现靠两样东西：单下划线_name的约定，和双下划线__name的名称改写机制。
所以学Python封装，第一步是扭转观念：Python的私有不是“锁”，而是“告示牌”。它告诉你“这里不该动”，但如果你非要动，解释器不会拦你，顶多就是你破坏了约定之后，后果自负。理解了这一点，后面所有细节都好说了。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 单下划线与双下划线：私有属性的“约定”与“伪装”
这一章是Python封装的核心机制，也是一大堆新手最容易混淆的地方。_x和__x虽然只差一个下划线，含义和使用场景却完全不同。
2.1 单下划线_name：写在PEP8里的受保护约定
单下划线开头的属性名，比如self._balance，在Python社区里代表的是：“这是一个内部属性，请外部不要直接访问，但我不强制禁止。”
它背后的权威依据是PEP8。PEP8中明确提到，_name这种单下划线前缀的命名方式，用来表示“受保护的成员”，含义是“仅内部使用，子类可以访问，但外部模块不要直接碰”。
注意，这里有一个很多人忽略的点：单下划线属性在子类中是可以访问的。也就是说，如果你写一个基类，里面有self._data，子类可以直接用self._data来读写，这在框架设计里非常常见。它表示的是“内部使用，但允许继承者扩展”。
我的习惯是：凡是需要保护、但又可能被子类重写或访问的属性，一律用单下划线。举个例子，写一个配置解析类，内部缓存 _config_dict，子类可能需要读取，我就用单下划线。这样既表明了态度，又没有把路堵死。
2.2 双下划线__name：解释器背后的名称改写机制
双下划线开头且结尾不是双下划线的属性名，比如self.__balance，触发的机制叫做name mangling（名称改写）。它不是简单的约定，而是解释器在编译阶段实实在在做了手脚。
具体来说，当你在类的内部写成self.__balance的时候，Python解释器会把它悄悄改写成self._ClassName__balance。注意，是类名前面加一个下划线，再拼上原来的属性名。
看一下实际效果：
python复制class Account:
def __init__(self, owner):
self.__balance = 0 # 被改写成 self._Account__balance
self.owner = owner
a = Account("Alice")
print(a.__dict__)
# 输出：{'owner': 'Alice', '_Account__balance': 0}
print(a.__balance)
# 报错：AttributeError: 'Account' object has no attribute '__balance'
print(a._Account__balance)
# 输出：0
看到没有？a.__balance直接访问会报错，但a._Account__balance可以正常访问。换句话说，双下划线不是真的“访问不了”，而是换了名字让你找不到。我把这个机制称为“伪装”，它确实比单下划线多了一层保护，但这层保护极其脆弱。
很多初学者看到这里会问：那这还有什么用？安全吗？答案是：这不是安全机制，是防误用机制。它真正目的是防止你手滑访问到内部属性，同时防止子类和基类的同名属性互相覆盖，这一点下面会细说。
2.3 双下划线在继承中的真正价值：防止属性覆盖
name mangling机制的设计初衷，我认为最重要的反而不是“防外部访问”，而是防止继承体系中父子类同名属性的覆盖冲突。
来看这个例子：
python复制class A:
def __init__(self):
self.__x = 1 # 实际存储为 self._A__x
class B(A):
def __init__(self):
super().__init__() # 先初始化 A，生成 _A__x
self.__x = 2 # 实际存储为 self._B__x
b = B()
print(b.__dict__)
# 输出：{'_A__x': 1, '_B__x': 2}
如果没有name