集合变量命名应使用复数形式明确表示多个同类数据，如users、orders；前置语义词强化业务意图，如activeUsers、cachedProducts；按需谨慎添加类型前缀如listPendingUpdates；布尔集合需体现判断逻辑，如allowedRoles，避免模糊词如data、list。

集合变量的命名不是“加个s”或“套个list”就完事，关键在于让名字本身说出它装的是什么、怎么用、为什么存在。

用复数形式明确表达“多个”

集合天然表示一组同类数据，命名必须体现这个本质。单数名容易让人误以为是单个对象，比如 user 看起来像一个用户实例，而 users 一眼可知是用户列表。

• 推荐：users、orders、productIds、pendingTasks、failedValidations
• 避免：userList、orderArray、productsList（冗余，“List”已由类型声明体现，命名中再写属于重复信息）

前置语义词强化业务意图

光说“多个”不够，还要说清“哪一类多个”。在复数名词前加入限定词，能快速传达上下文和用途。

• 按状态：activeUsers、expiredTokens、unprocessedMessages
• 按来源：cachedProducts、importedContacts、apiResponseItems
• 按操作阶段：validatedOrders、filteredResults、mergedEntries

这类命名比单纯叫 list 或 items 更具自解释性，读代码时无需跳转查看初始化逻辑就能理解其语义边界。

结合类型前缀（按团队约定谨慎使用）

部分团队采用前缀区分集合类型，如 listPendingUpdates、setLowStockItems、dictProductMapping。这种方式在大型项目或强类型语言（如C#、Java）中利于快速识别结构特征。

• 优势：与形参命名风格统一（如 _dictConfig），便于IDE自动补全和静态检查
• 注意：前缀应简短通用（list / set / dict / queue），且全项目保持一致；不建议混用，例如同时出现 userList 和 pendingUsers

布尔集合与特殊集合需额外提示

某些集合承载判断逻辑，命名应呼应其作用方式。

• 用于查找/存在性判断的集合：用 allowedRoles、blockedIps、supportedFormats，而非 roles 或 ips
• 空集合有业务含义时，可强调状态：emptyCategories（表示分类未配置）、defaultPermissions（表示初始权限集）
• 避免模糊词：data、info、list 等零信息量词汇不单独用于集合名