返回值类型由调用场景决定，需匹配业务契约：void用于无结果操作；optional仅当“不存在”是合法状态；泛型返回类型须与参数可推断；返回值还隐含不可变性、线程安全等契约承诺。
方法返回值类型不是设计出来的，是被调用场景倒逼出来的。选错类型会导致调用方必须写一堆 null 检查、类型转换或异常兜底，而问题往往在编译期不暴露，到运行时才崩。
返回 void 还是具体类型？看有没有“结果要交出去”
如果方法只做一件事（比如发通知、更新数据库、打日志），且调用方完全不关心执行后“得到什么”，就用 void。强行返回 boolean 表示“成功与否”反而误导——失败该抛异常，而不是让调用方自己判断 false 是网络超时还是主键冲突。
- ✅ 适合
void：sendEmail()、saveToCache()、logAccess() - ❌ 避免伪布尔：
boolean updateUser()—— 成功/失败语义模糊，异常信息丢失 - ⚠️ 注意：JPA 的
save()返回实体是因为它可能生成 ID 或触发拦截器，属于“有新东西要交还”，不是为了“告诉调用方成没成”
用 Optional<t></t> 还是 T 或 null？关键看“不存在”是否合法业务状态
Optional 不是用来替代 null 的银弹。它只应在“找不到”本身是正常流程的一部分时使用，比如按 ID 查用户，ID 可能根本不存在；但如果方法契约明确“必须返回一个对象”，那返回 Optional 就是在给调用方添堵。
- ✅ 合理用
Optional：findUserById(Long id)、getConfigValue(String key) - ❌ 滥用
Optional：calculateTotal(List<order> orders)</order>—— 输入为空列表？该抛IllegalArgumentException或返回0，不是Optional.empty() - ⚠️ 兼容性坑：不要把
Optional当作返回值放进publicAPI 的接口方法里——序列化、RPC、Mock 框架都容易翻车
泛型方法返回类型怎么写？别让类型参数“悬空”
泛型方法的返回类型必须和参数类型形成可推断关系，否则调用方每次都要显式写类型，失去泛型意义。常见错误是把类型参数只用在返回值里，参数却是 Object 或 ?。
立即学习“Java免费学习笔记（深入）”；
// ❌ 类型无法推断：编译器不知道 T 是 String 还是 Integer
public <T> T getValue() { ... }
// ✅ 类型由入参锚定：传 String[]，返回就是 String
public <T> T getFirst(T[] array) { return array[0]; }
// ✅ 或由入参类型变量约束：传 Map<K, V>，K 就确定了
public <K, V> K getKey(Map<K, V> map) { return map.keySet().iterator().next(); }
- ⚠️ 性能注意：泛型擦除后实际都是
Object，但过度嵌套泛型（如Function<supplier>>, Optional<t>></t></supplier>）会让代码难读、IDE 卡顿、编译报错信息更晦涩 - ⚠️ 工具链兼容：Lombok 的
@SneakyThrows和泛型方法一起用时，某些版本会丢掉类型信息，导致编译失败
最常被忽略的其实是返回类型的“契约重量”：它不只是告诉编译器怎么检查，更是向所有调用方承诺“我保证返回这个，且这个值的状态是可靠的”。比如返回 List，就得想清楚是返回不可变副本、线程安全实现，还是干脆让调用方自己 Collections.unmodifiableList() —— 这些细节不会出现在方法签名里，但一旦出问题，锅永远在返回值设计上。
