@property 是 Python 原生推荐的受控属性访问方式，优于 get_x()/set_x()：保持属性直觉、支持平滑升级、语义清晰、IDE 友好、兼容描述符协议；只读性由是否定义 setter 控制；避免在 property 中做耗时、有副作用或需参数的操作。
Python 不建议用 @property 替代普通 getter/setter 函数来“实现属性受控访问”——它本身就是 Python 原生支持的、更自然的受控访问方式，不是“替代方案”，而是“正确用法”。
为什么不用 get_x() 和 set_x() 这类函数？
显式调用 get_x() 破坏属性直觉：用户本该写 obj.x，却被迫写 obj.get_x()，既冗余又违背封装透明性。更关键的是，后期想把普通属性改成带逻辑的属性时，若已暴露 get_x 接口，就无法平滑升级——调用方代码必须全部改写。
用 @property 则无此问题：x 一开始是简单属性，后来加校验或计算逻辑，只需补上 @x.setter 和 @x.getter，所有 obj.x = 123 或 print(obj.x) 仍能照常运行。
- 普通方法名（如
get_name）会暴露实现细节，暗示“这是个函数调用”，而属性访问语义更贴近“获取状态” - IDE 和类型检查器（如 mypy）对
@property的识别远好于手写get_*方法，能提供准确的自动补全和类型推导 -
@property支持__set_name__协议（Python 3.6+），可配合描述符复用逻辑；手写 getter/setter 无法参与这一机制
@property 的 setter 为什么默认不可写？
定义只有 @property 装饰的 getter，属性就是只读的——尝试赋值会触发 AttributeError: can't set attribute。这不是缺陷，而是设计保护：很多属性本就不该被外部修改（比如计算属性 area 依赖 width 和 height）。
立即学习“Python免费学习笔记（深入）”；
若需可写，必须显式定义 @xxx.setter。这种分离强制你思考：“这个属性是否真该允许外部修改？修改时要不要校验？”
- 没写
@x.setter却想赋值 → 报错AttributeError: can't set attribute - 写了
@x.setter但没写@x.getter→ 会报AttributeError: unreadable attribute（getter 是必需的） - setter 中抛出异常（如
ValueError）比在普通方法里更符合“赋值失败”的语义直觉
什么时候不该用 @property？
当访问有明显副作用、耗时较长，或涉及 I/O、网络、复杂计算时，@property 就是反模式。属性访问在 Python 中默认被视为“轻量、无副作用”的操作，用户不会预期 obj.last_login_time 触发一次数据库查询。
- 耗时 > 1ms 的逻辑（如查缓存、序列化、远程调用）→ 改用显式方法，如
obj.load_config() - 可能改变对象状态（如
obj.is_processed设为True同时触发清理）→ 用方法，命名体现动作，如obj.mark_as_processed() - 需要传参（如
obj.value_at(timestamp)）→ 方法是唯一选择；@property不接受参数
兼容性和性能要注意什么？
@property 在所有 Python 版本中行为一致，但要注意 CPython 解释器下，它的调用开销略高于直接访问实例变量（约 2–3 倍函数调用成本），不过对绝大多数业务逻辑可忽略。真正影响性能的是 getter/setter 内部逻辑，不是装饰器本身。
另一个易忽略点：继承时重写 @property 需小心。子类若只重写 @x.getter，父类的 @x.setter 会丢失（除非显式重新绑定）。推荐统一用 @x.setter + @x.getter 成对定义，或使用 super().x.fget 手动复用。
- 不要在
@property中做日志打印、发 HTTP 请求等可观测副作用——调试困难且违反直觉 - 若属性需线程安全，
@property本身不提供锁；得在 getter/setter 内手动加threading.Lock - dataclasses 或 Pydantic 模型中，
@property无法被自动序列化（如model.dict()默认不包含 property 字段），这点常被忽略
