Set.clear() 是唯一可靠的一键清空方式，它原地修改实例、保持引用一致、时间复杂度 O(1)，而重赋值或遍历删除均存在引用丢失、行为不可靠或性能问题。
Set.clear() 是唯一可靠的一键清空方式
JavaScript 的 Set 没有类似数组的 length = 0 或赋值为新实例这种“看似清空”的捷径。直接重赋值 mySet = new Set() 看似有效，但会丢失原引用——如果其他变量或闭包里还持有这个 Set 实例，它们看到的仍是旧数据，不是真清空。
正确做法就是调用原生方法：clear()。它修改的是实例本身，所有引用都同步看到空状态。
-
mySet.clear()是唯一保证所有引用一致、且不改变对象身份的操作 - 不返回新
Set，返回undefined，别试图链式调用（mySet.clear().add(...)会报错） - 时间复杂度 O(1)，内部只是重置计数器和清空哈希表指针，比手动
for...of删除快得多
别用 Array.from(mySet).forEach(mySet.delete) 这类“伪清空”
常见错误是想“遍历删除”，比如 Array.from(mySet).forEach(item => mySet.delete(item))。这不仅多余，而且危险：在迭代过程中修改正在遍历的集合，行为不可靠——某些引擎可能跳过元素，或抛出隐式错误（尤其配合 Proxy 时）。
更隐蔽的问题是，delete 接收的是值，而 Set 的 delete() 对非严格相等的值无效（比如两个结构相同但内存地址不同的对象）。
- 即使当前能跑通，也依赖引擎实现细节，不跨版本稳定
- 如果
Set里存的是对象，Array.from创建的是浅拷贝引用，但delete()需要原始引用才能命中——稍有不慎就删不干净 - 性能差：O(n) 遍历 + O(1) 每次查找，实际开销远高于
clear()
clear() 在 WeakSet 中不可用，这是设计限制
如果你误把 WeakSet 当成普通 Set 来用，调用 clear() 会直接报错：TypeError: WeakSet.prototype.clear is not a function。这不是 bug，是规范故意不提供——因为 WeakSet 的键是弱引用，无法可靠枚举，自然也无法批量清除。
这意味着：一旦你选了 WeakSet，就只能靠让内部对象自然失活（被 GC）来“释放”，没有主动清空路径。
- 需要清空逻辑？立刻换回普通
Set，别硬扛 - 如果只是临时缓存且生命周期明确，用
WeakSet是对的，但得接受“不清空”这个事实 - TypeScript 类型检查不会拦住你写
weakSet.clear()，运行时才崩，注意测试覆盖
清空后 size 变成 0，但内存释放取决于引用关系
clear() 后 mySet.size 立即变为 0，但这只表示集合逻辑为空；原来存进去的对象是否被回收，完全看有没有其他变量还在引用它们。
比如你往 Set 里塞了一个大对象 const obj = { data: new ArrayBuffer(100 * 1024 * 1024) }，然后 mySet.add(obj)，再 mySet.clear()——只要 obj 变量还活着，那 100MB 内存就还在。
- 真正影响内存的是变量作用域和 GC 触发时机，不是
clear()本身 - 如果集合里存的是大量短生命周期对象，清空后它们大概率很快被 GC；但如果存的是全局变量引用的对象，清空毫无内存收益
- 调试时别只看
size，用浏览器 DevTools 的 Memory 面板确认实际释放情况
事情说清了就结束
