java 无法原生支持类型别名，但可通过定义语义明确的独立类（如 oldfoo 和 newfoo）或共享接口/抽象基类，在编译期强制区分两类数据，从根本上避免将旧列表误传给仅接受新列表的方法。
在 Java 中，List<Foo> 本身不携带语义信息——无论 oldFoos 还是 newFoos 都是 List<Foo> 类型，编译器无法识别其业务含义差异，因而极易发生误传（例如将历史兼容数据传入面向新版逻辑的处理器）。解决这一问题的核心思路是：让类型承载意图，而非依赖变量命名或运行时注释。
✅ 推荐方案：语义化子类（零运行时开销，强类型安全）
为“旧版”和“新版”分别定义不可互换的具体类型：
// 语义清晰、无继承关系 → 编译期完全隔离
final class OldFoo {
private final double someNum;
public OldFoo(double someNum) { this.someNum = someNum; }
}
final class NewFoo {
private final double someNum;
public NewFoo(double someNum) { this.someNum = someNum; }
}
// 方法签名即契约：只接受新版
class NewFooRunner {
public double runFoos(List<NewFoo> foos) {
return foos.stream()
.mapToDouble(f -> f.someNum)
.sum();
}
}此时以下调用会编译失败：
List<OldFoo> oldFoos = List.of(new OldFoo(1.0)); List<NewFoo> newFoos = List.of(new NewFoo(2.0)); new NewFooRunner().runFoos(oldFoos); // ❌ 编译错误：incompatible types new NewFooRunner().runFoos(newFoos); // ✅ 正确
⚠️ 注意：若 OldFoo 与 NewFoo 在业务上存在共性（如都需序列化、都含 id 字段），可提取公共接口（如 FooContract），但绝不应让二者共享父类或实现同一接口后用于泛型参数位置——否则仍会破坏类型隔离。接口仅用于跨场景通用能力，不用于替代类型区分。
? 进阶场景：需部分兼容时使用标记接口（轻量且灵活）
当某些工具方法需同时处理两类对象（如日志打印、基础校验），可引入空标记接口：
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
立即学习“Java免费学习笔记（深入）”；
interface FooVariant {} // 标记接口，无方法
interface OldFooVariant extends FooVariant {}
interface NewFooVariant extends FooVariant {}
final class OldFoo implements OldFooVariant { /* ... */ }
final class NewFoo implements NewFooVariant { /* ... */ }
// 兼容方法（接受任意变体）
void logAnyFoo(FooVariant foo) { /* ... */ }
// 专用方法（仅接受新版）
double runFoos(List<NewFooVariant> foos) { /* ... */ }此方式保持类型安全，又为必要场景提供扩展性。
? 不推荐方案说明
- 包装器类（如 NewFoos { List<Foo> }）：虽能隔离类型，但引入冗余封装、增加内存开销，且无法直接复用 List 的丰富 API（需手动委托），违背“类型即契约”的简洁性原则。
- 泛型类型参数（如 <T extends Foo>）：无法约束具体子类，仍可能传入错误类型。
- 运行时断言或注解（如 @Old / @New）：仅提供弱提示，无法阻止编译通过后的误用。
✅ 总结
| 目标 | 推荐做法 |
|---|---|
| 绝对禁止混用 | 定义互不相关的 OldFoo / NewFoo 类（无继承、无共同接口） |
| 部分场景需通用处理 | 使用标记接口分层（OldFooVariant / NewFooVariant） |
| 避免运行时风险 | 拒绝包装器、注解、字符串标识等非类型化手段 |
类型系统的真正价值，正在于将业务约束提前到编译期。用对一个类，胜过十行注释。
