弱引用包装类值设为nil时，是否会干扰Hashable集合的正常运作？

你这个推测完全说到点子上了！这确实是Swift中用哈希集合（比如Set）存储弱引用对象时极易踩的一个坑，我来帮你拆解清楚原因，再给你可行的解决办法。

问题根源 #

当被包装对象的deinit方法触发时，这个对象其实已经处于「即将销毁但尚未完全释放」的状态。如果你的弱引用包装类的hashValue（或者hash(into:)方法）是依赖被包装对象的属性/自身哈希值来计算的，那么当对象即将被释放时，弱引用指向的对象会被标记为nil，此时计算出的哈希值就会变成0（或者其他默认值）。

但问题在于：这个弱引用包装类实例在集合里的存储位置，是基于它存活状态下的哈希值计算出来的桶位置。当你在deinit里尝试移除它时，集合会用当前的哈希值（也就是0）去查找对应的桶，自然找不到原本存储的位置，移除操作也就失败了。

可行解决方案 #

方案一：缓存初始哈希值

在弱引用包装类初始化时，就把被包装对象的哈希值缓存下来，后续哈希计算直接使用这个缓存值，不再动态依赖即将销毁的对象。这样即使对象进入deinit阶段，哈希值也不会改变，集合就能正确定位到元素。

示例代码：

class WeakWrapper<T: AnyObject>: Hashable where T: Hashable {
    weak var value: T?
    private let cachedHash: Int
    
    init(value: T) {
        self.value = value
        self.cachedHash = value.hashValue
    }
    
    func hash(into hasher: inout Hasher) {
        hasher.combine(cachedHash)
    }
    
    static func == (lhs: WeakWrapper<T>, rhs: WeakWrapper<T>) -> Bool {
        // 用身份运算符判断对象是否为同一个，避免值比较的潜在问题
        return lhs.value === rhs.value
    }
}

方案二：基于对象身份计算哈希

直接使用被包装对象的内存地址（通过ObjectIdentifier）来生成哈希值——对象的内存地址在其生命周期内是固定的，哪怕进入deinit阶段，地址依然有效（直到真正被系统回收）。这样就能彻底摆脱对对象自身哈希值的依赖。

示例代码：

class WeakWrapper<T: AnyObject>: Hashable {
    weak var value: T?
    
    init(value: T) {
        self.value = value
    }
    
    func hash(into hasher: inout Hasher) {
        // deinit阶段对象尚未完全释放，value此时不为nil
        hasher.combine(ObjectIdentifier(value!))
    }
    
    static func == (lhs: WeakWrapper<T>, rhs: WeakWrapper<T>) -> Bool {
        return lhs.value === rhs.value
    }
}

额外注意事项 #

• 记得定期清理集合中value为nil的无效包装实例，避免内存冗余。比如可以在每次访问集合前，执行一次过滤：

  myWeakSet = myWeakSet.filter { $0.value != nil }
  

• 尽量让deinit方法的逻辑保持简洁，避免在其中做复杂的集合操作——毕竟此时对象状态已经不稳定，额外操作可能引发其他潜在问题。

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