该用@property做延迟加载当属性计算开销大且非每次必用时；需搭配缓存（如手动赋值或cached_property），避免重复计算，并考虑缓存时效性与失效机制。
什么时候该用 @property 做延迟加载
当某个属性的计算开销大（比如读文件、查数据库、解析 JSON）、且不是每次实例化都用得上时，就适合延迟加载。直接在 __init__ 里算，会拖慢初始化；而每次都重新算，又浪费资源。用 @property 把逻辑藏在访问时触发，是自然的选择。
但要注意：纯 @property 不带缓存，每次访问都重新执行函数——这反而更慢。真正起效的是“延迟 + 缓存”组合。
- 典型场景：
self.config从磁盘读 YAML、self.dataframe加载大型 CSV、self.api_client初始化 HTTP 会话 - 错误做法：只写
@property，没做任何缓存，结果比直接存实例变量还慢 - 关键判断：如果属性值在整个对象生命周期内不会变，缓存就是安全的
@property 加 setattr 手动缓存怎么写
最轻量、最可控的方式：第一次计算后，把结果直接赋给实例变量（比如 self._cached_result），后续访问直接返回它。不依赖外部库，兼容所有 Python 版本。
class ExpensiveLoader:
def __init__(self, path):
self.path = path
<pre class="brush:php;toolbar:false;">@property
def content(self):
if not hasattr(self, '_content'):
# 模拟高开销操作
with open(self.path) as f:
self._content = f.read().strip()
return self._content
- 必须用
hasattr(self, '_content')或getattr(self, '_content', None) is None判断，不能用if self._content is None——因为属性可能合法为None或空字符串 - 缓存变量名建议加下划线前缀（如
_content），明确表示它是内部缓存，非公开接口 - 这种方式线程不安全；多线程同时首次访问可能重复计算，但多数脚本场景可忽略
Python 3.8+ 推荐用 functools.cached_property
标准库已提供现成方案：cached_property 就是专为这个场景设计的。它自动处理首次计算、缓存、线程锁（Python 3.9+ 默认启用），代码更干净，语义更清晰。
from functools import cached_property
<p>class ExpensiveLoader:
def <strong>init</strong>(self, path):
self.path = path</p><pre class="brush:php;toolbar:false;">@cached_property
def content(self):
with open(self.path) as f:
return f.read().strip()
- 仅限 Python 3.8+；3.7 及以下需用三方库
cached-property（pip install cached-property） -
cached_property是只读的：一旦缓存，无法通过obj.content = xxx覆盖（会抛AttributeError），这点比手写更严格也更安全 - 若需要可重置缓存，只能手动删属性：
del obj.content，下次访问再触发计算
别忘了清理缓存的时机和方式
延迟加载+缓存不是一劳永逸。当底层数据变了（比如配置文件被外部修改），缓存就过期了。这时候需要主动失效，否则程序行为不可预期。
- 最简单方式：提供一个公共方法，比如
reload_config()，里面del self._config或del self.config - 不要试图在属性 getter 里自动检测文件修改时间——IO 开销可能抵消缓存收益，且容易出竞态
- 如果对象生命周期长、且数据变更频繁，考虑不用缓存，改用带 TTL 的 LRU cache（配合
functools.lru_cache和自定义 key），但要小心实例变量作为参数传入导致缓存污染
缓存本身不难，难的是想清楚“它该活多久”和“谁负责告诉它该死了”。这两个问题没答案，@property 再漂亮也只是空中楼阁。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
