Set值得吗：按这5步判断
Set值得吗？别看别人一去重就 new Set，你也跟着抄。它值不值得用，要看数据规模、查询频率、业务语义和维护成本。按下面这套流程走，基本不会为了“高级感”写出反效果。
第1步：确认你处理的是“集合”
先别写代码，先看业务话术。如果需求说的是“已选中的用户ID”“黑名单手机号”“允许访问的角色码”，这些天然是集合，Set 很值得考虑。
如果需求说的是“列表第几项”“按创建时间展示”“允许重复记录”，那就停手。Set 没有下标，也不表达重复次数。用错容器，比不用优化更麻烦。
第2步：估算数据量和查询次数
Set值得吗，性能上主要看两个数字：集合有多大、要查多少次。几十个元素、查一两次，用数组就挺好，代码清楚。
如果是几千个ID反复判断，比如权限过滤、商品收藏、批量选中状态，Set 的价值就出来了。建 Set 有成本，但大量 has 查询能把成本摊掉。
第3步：检查数据类型是否稳定
Set 对类型很严格。1 和 "1" 不是同一个值。线上最烦的 bug 往往不是 Set 本身，而是接口A给数字ID，接口B给字符串ID。
上 Set 前，最好在数据适配层统一类型。比如所有ID都转字符串，或者都转数字。别在每个 has 前面临时转换，那样代码会像贴满创可贴。
第4步：设计好输入输出边界
Set 很适合在内存里用，但不适合直接存接口或 localStorage。需要传输、缓存、打印给人看时，数组更通用。
实操建议：接口进来是数组，业务内部需要就转 Set；接口发出去前再转数组。这个边界固定下来，团队协作会顺很多，不会有人拿到一个 Set 后不知道怎么序列化。
第5步：用一条小规则收尾
我的判断规则很简单：只关心唯一性和存在性，用 Set；关心顺序、位置、重复，用 Array；关心键值映射，用 Map。
所以 Set 值得吗？在“ID集合、高频查询、去重、选择状态”里很值得；在“小数据、展示列表、对象内容去重”里别硬上。工具越简单，越要放在对的位置。
常见问题
- Set值得在小项目里用吗？
- 值得，但别滥用。去重、选中ID、权限码这些场景用 Set 很清爽；普通列表没必要强行改。
- Set会不会影响代码可读性？
- 用在集合语义里反而更清楚。真正影响可读性的是一会儿数组一会儿 Set，边界没定好。
- Set适合存到localStorage吗？
- 不适合直接存。先转数组再 JSON.stringify，读取后如有需要再 new Set。