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