使用Collectors.toMap时，Key预处理必须在keyMapper函数中完成，如u->u.getEmail().trim().toLowerCase()；重复Key需提供mergeFunction处理，禁止在valueMapper中修改对象影响Key。

使用 Collectors.toMap 时，Key 的格式化预处理必须在映射函数（即第一个参数）中完成，不能依赖 Map 的 KeySet 后续修改——因为 Key 是构建时确定的，且要求不可变、一致。

在 keyMapper 函数中直接格式化

这是最常用也最安全的方式：把原始字段提取 + 格式化逻辑全部写进 keyMapper 的 lambda 或方法引用里。

• 例如将用户邮箱转为小写并去除前后空格作为 Key：

Map<String, User> userMap = users.stream()
    .collect(Collectors.toMap(
        u -> u.getEmail().trim().toLowerCase(), // ✅ Key 预处理在此完成
        Function.identity()
    ));

• 再比如用 ID 拼接前缀、补零或截取子串：

u -> "U_" + String.format("%06d", u.getId())

复用已有工具方法或自定义函数

当格式化逻辑较复杂或需多处复用时，建议抽出成静态方法或函数式接口实例，提升可读性和可维护性。

• 定义工具方法：

private static String normalizeEmail(String email) {
    return Optional.ofNullable(email)
                   .map(String::trim)
                   .filter(e -> !e.isEmpty())
                   .map(String::toLowerCase)
                   .orElse("unknown@example.com");
}

• 在 toMap 中调用：

.collect(Collectors.toMap(
    u -> normalizeEmail(u.getEmail()),
    Function.identity()
))

注意重复 Key 导致的 IllegalStateException

格式化后 Key 若出现重复（如两个不同邮箱经 trim+toLowerCase 后相同），toMap 默认会抛异常。此时需提供 mergeFunction 处理冲突：

• 保留第一个值（静默跳过后续）：

(existing, replacement) -> existing

• 或合并信息（如记录冲突数量、拼接 name）：

(u1, u2) -> new User(u1.getId(), u1.getName() + "/" + u2.getName(), ...)

避免在 valueMapper 中“顺手”改 Key

Key 的生成和 Value 的构造是分离的。不要试图在 valueMapper 里修改 Key 对应的对象状态来间接影响 Key 行为——这既无效也不符合函数式语义。

• 错误示例（Key 已固定，改对象无意义）：

.collect(Collectors.toMap(
    User::getEmail,
    u -> { u.setEmail(u.getEmail().trim()); return u; } // ❌ 不影响 Key
))