Set.prototype.has 是唯一正解，不存在“秒级优化”空间；它是 O(1) 哈希查找，瓶颈在于误用数组 includes、临时构造 Set 或对象引用语义误判，而非 has 本身。
Set.prototype.has 是唯一正解，不存在“秒级优化”空间
JavaScript 的 Set.prototype.has 本身就是 O(1) 平均时间复杂度的哈希查找，没有更“快”的替代方案。所谓“秒级检测”其实是误解——它本来就是瞬时完成的，瓶颈从来不在 has 自身，而在你是否误用了其他数据结构或触发了隐式类型转换。
常见错误：用数组 includes 代替 Set has
开发者常把 Array.includes 当作等价方案，但这是线性遍历，数据量稍大（比如 >1000 项）就明显卡顿。而 Set.has 不受元素数量影响，只要哈希值计算稳定，查找耗时几乎恒定。
- ✅ 正确：用
new Set([1, 2, 3])存储后调用set.has(2) - ❌ 错误：反复对
[1, 2, 3].includes(2)做判断（尤其在循环或高频事件中） - ⚠️ 注意：
Set对NaN和0的处理与严格相等一致（NaN === NaN为false，但set.has(NaN)能正确返回true）
容易被忽略的坑：对象/函数作为 key 时的引用语义
Set 判断存在性基于引用（对于对象、函数），不是深比较。同一个对象实例多次 add 不会重复，但两个字面量相同的新对象会被视为不同元素。
const s = new Set();
const obj1 = { id: 1 };
const obj2 = { id: 1 };
s.add(obj1);
console.log(s.has(obj1)); // true
console.log(s.has(obj2)); // false —— 即使内容一样，引用不同
- 若需按内容查，得自己实现缓存逻辑（如用
JSON.stringify+ Map，但注意循环引用和 key 顺序） - 函数同理：
s.add(() => {}); s.has(() => {})永远是false - 原始值（string/number/boolean/symbol/undefined/null）完全安全，可直接用
has
性能敏感场景下，别让 Set 构造成为瓶颈
如果你每次检测前都临时构造 Set（比如 new Set(arr).has(x)），那开销全花在初始化上，比 arr.includes 还慢。必须复用已构建好的 Set 实例。
- ✅ 预先构建：
const validIds = new Set([101, 102, 103]);，后续只调用validIds.has(id) - ❌ 临场构造：
if (new Set([101, 102, 103]).has(id)) { ... }—— 每次都重建哈希表 - ⚠️ 注意：
Set内部存储的是值本身，不是拷贝；修改原对象不影响has结果（因为不依赖属性值）
实际效果取决于你怎么初始化和复用，而不是怎么调用 has。写错一次构造方式，比调用一千万次 has 更伤性能。
