Java方法不能直接返回多个值，应通过设计专用不可变结果类（如record或传统class）、谨慎使用标准库容器、按状态分层封装响应（如Result<T>或CommonResponse<T>）来实现类型安全、语义清晰的多值返回，避免Object[]、Map<String,Object>等不安全方式。
Java 方法不能直接返回多个值，但可以通过封装对象来合理返回多个计算结果或复杂状态。关键在于设计清晰、职责明确的返回类型，避免使用 Object[] 或 Map 等泛型容器导致类型不安全和可读性差。
定义专用结果类（推荐）
为特定业务场景创建不可变的、语义明确的结果类，是最安全、可读性最强的方式。
- 字段用
final修饰，构造器一次性初始化，保证线程安全与不可变性 - 提供有意义的 getter（不暴露 setter），必要时加
toString()和equals/hashCode - 命名体现用途，例如
CalculationResult、ValidationOutcome、ApiResponse
示例：
public record CalculationResult(double sum, double avg, int count, boolean isValid) {}
// 或传统 class（兼容老版本）
public class ValidationOutcome {
private final boolean passed;
private final List<String> errors;
private final long durationMs;
public ValidationOutcome(boolean passed, List<String> errors, long durationMs) {
this.passed = passed;
this.errors = List.copyOf(errors);
this.durationMs = durationMs;
}
// getter...
}
使用标准库中的通用容器（谨慎选择）
当结果结构简单且临时性强时，可考虑 Pair / Triple（如 Apache Commons Lang 或 Vavr），但需注意：
立即学习“Java免费学习笔记（深入）”；
- 仅适用于短生命周期、内部逻辑中；对外 API 不建议暴露
Pair<String,Integer>这类模糊语义类型 - Java 14+ 可用
record快速声明轻量级容器，比泛型 Pair 更具可读性 - 避免用
Map<String,Object>返回结果——丢失编译期类型检查，易引发运行时异常
按状态分层返回（面向契约设计）
对于含“成功/失败”语义的操作，推荐用状态明确的封装类型，而非靠返回 null 或异常传递业务失败信息。
- 自定义
Result<T>类（含 success/failure 分支），类似 Rust 的 Result 或 Scala 的 Try - Spring 项目中可结合
ResponseEntity<T>或统一响应体（如CommonResponse<T>） - 失败时携带错误码、消息、上下文数据（如校验字段名、原始输入），便于前端或调用方精准处理
示例结构：
public class CommonResponse<T> {
private int code; // 0=success, others=error
private String message;
private T data;
private Map<String, Object> metadata; // 可选：分页信息、traceId 等
}
避免常见陷阱
以下做法会降低可维护性，应尽量规避：
- 返回
Object[]：调用方需记住下标含义，极易出错且无法 IDE 提示 - 用
void+ 输出参数（如AtomicInteger或自定义 holder 类）：破坏函数式风格，增加理解成本 - 过度复用同一结果类承载不同语义（如所有接口都返回
BaseResult）：丧失领域表达力，后期难以演进 - 在结果对象中暴露可变集合（如返回
ArrayList而非unmodifiableList）：破坏封装，引发并发或意外修改风险
