高内聚集合工具类应按语义层垂直拆分：过滤校验、转换组装、聚合计算、安全操作四类，每类职责单一、无状态、参数扁平、命名动词开头，复杂业务规则应提取为接口而非塞入工具类。
在复杂业务中设计高内聚的集合工具类，核心不是“把所有集合操作塞进一个类”，而是让每个工具类只专注一类集合行为、无状态、可预测、易替换——它应是业务逻辑的支撑者，而非逻辑本身。
职责必须单一，按领域垂直拆分
避免出现 CollectionUtils 或 CommonListUtils 这类泛称。复杂业务中集合操作天然分化为不同语义层：
-
过滤与校验类（如
OrderFilterUtils）：只封装与订单相关的筛选逻辑，如filterByStatus(List<Order>, OrderStatus)、hasDuplicateSku(List<Item>) -
转换与组装类（如
OrderDtoAssembler）：负责List<OrderEntity>→List<OrderSummaryDto>，不掺杂校验或持久化 -
聚合计算类（如
OrderMetricsUtils）：提供sumTotalAmount()、avgDeliveryDays()等统计方法，输入纯数据，输出确定数值 -
安全操作类（如
ImmutableListUtils）：专用于生成不可变副本、空安全包装、null-aware 合并等，不处理业务规则
方法必须无状态且参数扁平
集合工具方法本质是纯函数：相同输入必得相同输出，不读写任何静态变量、不依赖外部配置、不修改入参集合。
- 禁止使用
static Map<String, List<?>> cache缓存中间结果——缓存应由调用方或专门的CacheService管理 - 参数尽量控制在 3 个以内，优先接收原始集合 + 明确语义的条件对象（如
OrderFilterCriteria），而非传入Map<String, Object>或自定义上下文 - 对入参做前置校验：
Objects.requireNonNull(orders, "orders must not be null")，失败抛IllegalArgumentException，不静默返回空集合
命名动词开头，语义直击意图
方法名要让人一眼看懂“它做什么”，而不是“它在哪用”：
立即学习“Java免费学习笔记（深入）”；
- ✅
toGroupedMapByOrderId(List<OrderLine>)—— 明确动作（转为 Map）、依据（byOrderId）、输入类型 - ✅
removeExpiredAndLock(List<Inventory>, LocalDateTime now)—— 动作清晰、条件明确 - ❌
process(List<?> input)、handle(List<T> data)—— 语义模糊，需点进源码才能理解
配合接口隔离，避免工具类成为耦合枢纽
当集合操作开始涉及业务规则（比如“筛选可发货订单”需查库存、验风控状态），就说明它已超出工具范畴——此时应退后一步，定义接口：
- 提取
OrderEligibilityChecker接口，声明isShippable(Order order) - 让具体实现类（
StockAndRiskBasedChecker）承担状态判断 - 工具类只保留
filter(list, checker::isShippable)这种通用委托方法 - 这样既保持工具类轻量，又把变化关进接口边界里，新增风控规则只需加实现类，不碰工具代码
