最稳妥的方式是直接调用 len() 并捕获 TypeError，因为即使 len 存在且可调用，其返回值非法（如负数、非整数）仍会导致 len() 抛异常，而异常处理最终必不可少。
直接检查 __len__ 方法是否存在
最稳妥的方式不是调用 len() 再捕获异常，而是提前确认对象是否实现了 __len__。Python 的 len() 本质就是调用对象的 __len__ 方法并要求返回非负整数，所以只要该方法存在且可调用，len() 就不会因“不支持”而报 TypeError。
但要注意：hasattr(obj, '__len__') 不够可靠——有些对象（比如某些 C 扩展类型或自定义描述符）可能有 __len__ 属性但不可调用，或者返回值非法（如负数、非整数），此时 len() 仍会抛异常。
- 推荐用
getattr(obj, '__len__', None)获取方法，再用callable()判断是否可调用 - 如果只需要快速判断且能接受极少数误判，
hasattr(obj, '__len__')更简洁 - 避免用
isinstance(obj, collections.abc.Sized)：虽然语义准确，但会触发 ABC 的注册检查和元类逻辑，对性能敏感场景（如高频循环）有开销
用 try/except 捕获 TypeError 更实际
在多数业务代码中，“先检查再调用”不如“直接调用，出错再处理”来得简洁可靠。因为即使 __len__ 存在且可调用，它仍可能在运行时抛出 TypeError（比如返回 float 或 None），最终还是要靠异常处理兜底。
示例：
立即学习“Python免费学习笔记（深入）”；
def safe_len(obj):
try:
return len(obj)
except TypeError:
return None # 或抛出自定义异常、返回 -1 等
- 只捕获
TypeError，不要用裸except:——len()不会抛ValueError或AttributeError，捕其他异常会掩盖真实问题 - 注意：某些对象（如生成器、某些迭代器）没有
__len__，但len()报的也是TypeError，不是AttributeError - 如果函数需频繁调用，且多数输入确实支持
len()，try/except的性能反而优于属性检查
collections.abc.Sized 的适用边界
isinstance(obj, collections.abc.Sized) 是语义最清晰的判断方式，符合 Python 的抽象基类设计哲学。但它依赖 __subclasshook__ 和注册机制，因此有几点限制：
- 内置类型（如
list、str、dict）默认是Sized的子类，没问题 - 用户自定义类若未显式继承或注册，即使实现了
__len__，isinstance(..., Sized)也可能返回False - 第三方库中部分类型（如
numpy.ndarray）虽支持len()，但未注册为Sized，导致检查失败 - 在类型检查工具（如 mypy）中，
Sized是推荐的静态提示方式，但运行时不一定等价
容易被忽略的细节：__len__ 返回值必须是非负整数
即使对象有可调用的 __len__，如果它返回负数、浮点数、None 或其他类型，len() 仍会立刻抛 TypeError: 'xxx' object cannot be interpreted as an integer 或类似信息。
这意味着：仅检查 __len__ 存在性或可调用性，并不能 100% 保证 len() 成功。真正安全的做法，始终是执行 len() 并捕获 TypeError——除非你完全信任该对象的实现。
