hasattr返回false不表示属性不存在，而是访问时抛出异常；它会静默吞掉@property中任何异常并返回false，因此不可靠，应改用getattr配合try/except处理。
hasattr 返回 False 却实际有属性？先检查 @property 是否抛异常
hasattr(obj, 'attr') 返回 False，不代表属性不存在——它只代表「访问该属性时没抛出 AttributeError」。而 @property 方法若在计算过程中主动抛出任何异常（比如 KeyError、TypeError、甚至 ValueError），hasattr 都会静默吞掉并返回 False。这是最常被忽略的根源。
实操建议：
- 不要依赖
hasattr判断@property是否“可用”，它本质是「异常探测器」而非「存在探测器」 - 用
getattr(obj, 'attr', sentinel)替代，再检查返回值是否为sentinel；或直接try/except捕获具体异常 - 在 property 的 getter 里加日志或断点，确认是否真在计算时出错（比如字典取键失败、未初始化的缓存、外部 API 调用失败）
为什么 hasattr 对 @property 特别危险？因为它捕获所有异常
hasattr 底层等价于 try: getattr(obj, name); except AttributeError: return False ——但注意：CPython 实现中，它实际捕获的是 所有 异常，只要不是 AttributeError 就重新抛出；然而从 Python 3.2 开始，为兼容性，它对 任何异常 都返回 False（见 bpo-10247）。这意味着：@property 里哪怕只是写了 1/0，hasattr 也返回 False，且不报错、不提示。
实操建议：
- 永远不要在
@property的 getter 中抛非AttributeError的异常（除非你明确知道调用方会处理） - 若必须抛其他异常，请在文档或类型注解中标明，避免使用者误用
hasattr - 测试时对每个
@property单独调用，观察是否真能成功求值，而不是只测hasattr
替代方案：用 getattr + 显式异常处理更可靠
想安全判断一个属性是否可读且无异常，getattr 配合 try/except 是唯一可控方式。尤其当属性可能因状态（如未登录、未加载数据）而临时失效时，你需要区分「属性不存在」和「属性存在但当前不可用」。
示例：
try:
val = getattr(obj, 'cached_result')
except KeyError: # property 内部抛了 KeyError
val = None
except AttributeError: # 真正不存在
val = None
实操建议：
- 用
getattr(obj, 'attr', _MISSING)只能防AttributeError，对@property内部异常无效 - 如果 property 逻辑复杂，考虑把核心计算提取成普通方法（如
get_cached_result()），让调用方自行决定是否捕获异常 - 用
inspect.isdatadescriptor或inspect.getmembers查看属性是否为property，提前预警风险
容易被忽略的边界：__getattr__ 和动态属性也会触发相同问题
不只是 @property，任何通过 __getattr__、__getattribute__ 或 __dict__ 动态生成的属性，只要其获取逻辑抛异常，hasattr 都会返回 False。例如 ORM 模型中字段延迟加载失败、代理对象后端连接断开、或 __getattr__ 里调用了已关闭的资源。
实操建议：
- 在
__getattr__中尽量只抛AttributeError；其他错误应转为日志+默认值，或由上层显式处理 - 调试时用
obj.__class__.__dict__.get('attr')快速确认是否为property或描述符，绕过运行时逻辑 - 生产环境慎用
hasattr做业务分支判断，它掩盖了真正的问题信号
真正麻烦的不是 hasattr 返回 False，而是它让你以为“没问题”——直到某个 @property 在关键路径上静默失败，而你还在检查拼写。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
