使用defaultdict.__len__生成连续ID的Python技巧是否存在潜在问题？

这个技巧确实挺聪明的，用defaultdict的default_factory绑定自身的__len__来自动给新键分配连续ID，在简单场景下很好用，但它确实存在几个容易被忽略的非预期问题：

• 并发环境下的竞态条件
  因为获取__len__和给键赋值这两个操作不是原子性的。如果多个线程同时尝试访问不存在的键，可能会出现两个不同的键被分配到同一个ID的情况。比如线程A拿到当前长度为2，还没完成赋值；线程B也拿到长度2，结果两个键都被分配ID 2，直接导致冲突。

• 手动修改字典会破坏ID连续性/唯一性
  如果你手动删除了某个键，或者手动给某个键赋值了一个非连续的ID，后续自动分配的ID就会出问题。比如原本字典有3个键（ID 0、1、2），删除一个后长度变成2，此时新键会被分配ID 2——但这个ID之前已经被用过了，直接重复；要是你手动给ids['test'] = 5，下一个自动分配的ID会是基于当前长度的1，和5完全不连续，打乱了整个ID序列的逻辑。

• 序列化/反序列化后可能失效
  如果你用pickle之类的工具把这个defaultdict序列化保存，之后反序列化回来，虽然default_factory还会绑定到实例的__len__，但如果序列化前你手动修改过字典内容，反序列化后的ID分配逻辑就会和之前的状态脱节。比如序列化前字典里有ID 0、1、2，反序列化后你添加新键，会基于当前长度3分配ID 3，这看起来没问题，但要是你序列化前删除过键，反序列化后的长度和实际已用ID的最大值不一致，就会出现重复ID。

什么时候这个技巧是安全的？ #

如果是单线程环境，并且你完全不手动修改字典（只通过访问不存在的键来触发自动ID分配），那这个方法非常简洁高效，不会有问题。

更健壮的替代实现 #

如果需要避免上述问题，或者需要更可控的ID分配逻辑，可以自己封装一个简单的类：

class IDMapper:
    def __init__(self):
        self.key_to_id = {}
        self._next_id = 0

    def __getitem__(self, key):
        if key not in self.key_to_id:
            self.key_to_id[key] = self._next_id
            self._next_id += 1
        return self.key_to_id[key]

    # 可以按需添加其他方法，比如根据ID查键、删除键（注意删除后_next_id不回退，避免重复）
    def get_key(self, id_):
        for key, val in self.key_to_id.items():
            if val == id_:
                return key
        return None

这个实现用独立的_next_id来追踪下一个要分配的ID，不依赖字典长度，完全避免了上述的各种坑，而且扩展性更强。

内容的提问来源于stack exchange，提问作者Davis Yoshida