__len__ 必须返回非负整数且不能懒计算，因其被 len() 强制调用并要求即时返回 int；可行方案是用实例属性缓存长度，由外部显式更新，__len__ 仅透传该值。
为什么 __len__ 必须返回 int 且不能懒计算
len() 的底层调用强制要求 __len__ 返回非负整数，且不能是 None 或延迟对象（比如 functools.cached_property 包裹的函数）。一旦返回值不是 int，就会抛出 TypeError: object of type 'X' has no len()。更关键的是，__len__ 在每次 len(obj) 调用时都会执行——它天然不缓存，也不支持“外部计算后注入”的语义。
用属性代理 + 外部更新模拟“外部计算长度”
真正可行的做法是：把长度值存在实例属性里，由外部逻辑负责设置；__len__ 只做透传。这规避了协议限制，也符合“实际长度由外部计算”的需求。
-
__len__内直接返回一个实例变量（如self._cached_len），不参与计算 - 外部代码在需要时调用类似
obj._update_length()或直接赋值obj._cached_len = compute_real_length(obj) - 如果想防止误用，可加一层检查：
if not hasattr(self, '_cached_len'): raise RuntimeError("length not initialized") - 注意：该方案不自动同步，外部必须显式更新，否则
len(obj)返回过期值
避免踩坑：不要在 __len__ 里调用外部函数
常见错误是试图在 __len__ 中触发网络请求、查数据库或遍历大文件——这会让所有依赖 len() 的代码（比如 if obj:、for 循环判断、list(obj)）变得不可预测且极慢。
- Python 很多内置行为隐式调用
len()，例如bool(obj)在未定义__bool__时会 fallback 到len(obj) != 0 - 第三方库（如 Pydantic、NumPy、Django ORM）也可能在序列化或验证时读取
len() - 若外部计算成本高，应在业务逻辑层主动缓存结果，再写入
_cached_len，而不是塞进__len__
示例：带手动刷新的可长度化容器
class LazyLenList:
def __init__(self, items):
self.items = items
self._cached_len = None # 初始未计算
def __len__(self):
if self._cached_len is None:
raise ValueError("length not computed yet. Call update_length() first.")
return self._cached_len
def update_length(self):
# 外部计算逻辑放这里，比如过滤、IO、聚合等
self._cached_len = len([x for x in self.items if x > 0]) # 示例：只算正数
使用时必须先调用 obj.update_length()，再用 len(obj) —— 这个控制权交给了使用者，也明确了“长度非实时”的契约。
真正难的不是实现，而是让所有协作者意识到：这个 len() 不是自洽的，它依赖外部状态同步。漏掉一次 update_length()，后续所有基于长度的判断都可能错。
