Collectors.toMap 动态选最优值的核心是将择优策略封装进 mergeFunction，支持按时间、优先级等维度比较，并需预处理、防空、确保 key 唯一与可比较。
用 Collectors.toMap 实现“按业务规则动态选最优值”映射，核心不是硬编码逻辑，而是把选择策略封装进 mergeFunction 参数，并结合预处理或分组提升可读性与健壮性。
明确“最优”的定义并提取为合并逻辑
所谓“最优”，可能是取最大值、最新时间、最高优先级、最长字符串，或自定义比较器结果。关键在于：它必须能表达为一个二元函数 (v1, v2) -> result，即当 key 冲突时，决定保留哪个 value。
- 比如按更新时间选最新记录：
(old, current) -> current.getUpdateTime().isAfter(old.getUpdateTime()) ? current : old - 比如按优先级字段选最高（数值越大优先级越高）：
(a, b) -> a.getPriority() >= b.getPriority() ? a : b - 避免直接写复杂逻辑；建议抽取为静态方法或方法引用，例如
MyMerger::pickLatestByTime
用 groupingBy + collectingAndThen 预分组再择优（适合多条件筛选）
若“最优”依赖多个维度（如先按类型分组，再在每组内按权重选 Top1），直接用 toMap 容易混乱。更清晰的做法是先分组，再对每组应用择优逻辑：
list.stream().collect(groupingBy(Item::getType, collectingAndThen(maxBy(comparing(Item::getScore)), Optional::get)))- 这样既保持语义清晰，又复用 JDK 已有收集器（如
maxBy、minBy、reducing） - 若需返回 Map<K, V>，最后用
collectingAndThen(..., map -> map)或转成toMap即可
处理空值与异常，让 mergeFunction 更健壮
真实业务中，value 可能为 null，或比较字段缺失。mergeFunction 必须主动防御，否则抛 NullPointerException：
- 统一判空前置：
(a, b) -> { if (a == null) return b; if (b == null) return a; return compare(a, b) ? a : b; } - 用
Comparator.nullsLast()或nullsFirst()包装比较器，例如comparing(Item::getScore, nullsLast(naturalOrder())) - 不建议在 mergeFunction 中 throw 异常——它不是设计来报错的，应降级处理（如留旧值、打日志、返回默认对象）
避免 key 冲突外的陷阱：确保 key 稳定且可比较
toMap 要求 key 不重复，但业务 key（如 name、code）可能天然重复。此时不能强求“去重”，而应确认是否真需要唯一 key：
- 如果 key 本就该唯一（如 ID），检查数据源是否脏（重复 ID、缓存未刷新）
- 如果 key 天然非唯一（如商品类目名），应改用复合 key（如
category + "-" + region）或改用groupingBy - key 对象若为自定义类，务必重写
equals/hashCode；用 String 作 key 最安全
不复杂但容易忽略：mergeFunction 是整个动态择优的灵魂，把它写清楚、测充分，比堆砌 Stream 链更重要。
