@property装饰器将无参方法转为只读属性，调用时无需括号，仍可执行校验、缓存等逻辑；加@xxx.setter和@xxx.deleter可支持赋值与删除，setter参数仅限self和value，deleter仅限self。
property怎么让方法像属性一样被调用
直接用 @property 装饰一个无参方法，它就变成只读属性了。调用时不用加括号，但背后仍是方法执行——这意味着你可以在里面做校验、缓存、日志等逻辑，而对外保持属性访问的简洁性。
常见错误是忘了去掉方法的括号：写成 obj.value() 会报 TypeError: 'int' object is not callable，因为 value 已经是属性，不是函数了。
- 必须是实例方法，且不能有除
self外的参数 - 返回值会被当作属性值，类型完全由方法体决定
- 不加
@property就只是普通方法；加了之后就不能再用()调用
class Circle:
def __init__(self, radius):
self._radius = radius
<pre class='brush:python;toolbar:false;'>@property
def area(self):
return 3.1416 * self._radius ** 2c = Circle(5) print(c.area) # ✅ 正确：像属性一样访问
print(c.area()) # ❌ 报错：'float' object is not callable
怎么给property加setter和deleter
只读不够用？那就补上 @xxx.setter 和 @xxx.deleter。注意：setter 方法名必须和 property 方法名一致，且**参数只能是 self 和新值（通常叫 value）**；deleter 则只接受 self。
立即学习“Python免费学习笔记（深入）”；
典型陷阱是 setter 里没处理非法输入，导致数据不一致。比如给半径赋负数，area 属性却照常计算——这不是封装，是掩耳盗铃。
图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍
- setter 不会自动触发 getter，它们是独立逻辑
- 如果没定义 setter，该属性就是只读，尝试赋值会抛
AttributeError - deleter 中建议清理关联状态，比如把缓存设为
None或重置标志位
@property
def radius(self):
return self._radius
<p>@radius.setter
def radius(self, value):
if value < 0:
raise ValueError("Radius must be non-negative")
self._radius = value</p><h1>注意：这里不自动更新 area，下次访问 area 时才会重新计算</h1><p>@radius.deleter
def radius(self):
self._radius = 0
property和__getattr__混用时谁先生效
property 优先级高于 __getattr__。只要类里明确定义了某个 property，哪怕它抛异常，也不会掉进 __getattr__ 的兜底逻辑。
这在做“懒加载属性”或“兼容旧字段名”时特别关键。比如你想让 obj.name 先走 property，失败了再查 obj._legacy_name，就不能依赖 __getattr__，得在 property 方法里手动处理 fallback。
-
__getattribute__比 property 更早，但它会拦截所有属性访问，滥用容易出递归错误 - property 是 Python 层的描述符协议实现，本质是
__get__方法被调用 - 动态生成大量 property？别硬写一堆装饰器，考虑用
property()函数配合setattr()
什么时候不该用property
当方法涉及 I/O、网络请求、复杂计算且调用频繁时，用 property 会掩盖性能开销。使用者看到 obj.data 会默认这是轻量访问，结果每次都在发 HTTP 请求。
另一个高危场景是 property 内部修改了对象状态（比如自增计数器），却没配文档说明——这违反属性访问的“无副作用”直觉，后续调试会很痛苦。
- 耗时超过几毫秒的操作，改用显式方法名，如
obj.fetch_data() - 需要传参的逻辑，硬塞进 property 只会让接口变扭曲，比如
@property+@xxx.setter无法支持多参数 - 继承链中子类想覆盖父类 property 行为？不如直接重写整个 getter/setter，别试图在子类里只重定义其中一个
property 的核心价值是把“应该封装但又需要自然访问”的逻辑藏好。一旦开始纠结要不要加 cache、要不要加锁、要不要异步，说明它已经超纲了——这时候该换方案，而不是给 property 套更多层。
