通过为旧版和新版数据定义独立类（如 oldfoo 和 newfoo），利用 java 类型系统实现编译期隔离，可彻底杜绝将旧列表误传给仅接受新列表的方法。
在 Java 中，仅靠泛型 List
✅ 推荐方案：语义化类型建模（零运行时开销）
定义两个无继承关系的独立类，即使结构一致，也强制类型不兼容：
// 语义明确、互不兼容的类型
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; }
}
// 方法签名即文档：只接受 NewFoo
class NewFooRunner {
public double runFoos(List foos) {
return foos.stream()
.mapToDouble(f -> f.someNum)
.sum();
}
} 此时以下代码将编译失败，精准拦截错误：
ListoldFoos = List.of(new OldFoo(1.0)); List newFoos = List.of(new NewFoo(2.0)); new NewFooRunner().runFoos(oldFoos); // ❌ 编译错误：incompatible types new NewFooRunner().runFoos(newFoos); // ✅ 正确
⚠️ 注意事项与权衡
-
避免滥用继承或接口：若为 OldFoo 和 NewFoo 引入共同父类（如 abstract class Foo）或接口（如 interface Foo），会削弱类型安全——List
可同时容纳两者，失去隔离意义。 -
不要用包装类绕过类型系统：如 class NewFoos { List
data; } 虽能隔离，但增加了冗余封装、破坏了集合操作的自然性（无法直接用 stream()/forEach()），且未解决根本问题（Foo 本身仍无语义）。 - 工具链友好：IDE 自动补全、静态分析（如 ErrorProne）、重构支持均能识别语义类型，提升协作效率。
- 演进考量：未来若 NewFoo 新增字段或行为，可独立演进，不影响 OldFoo 的稳定性。
总结
Java 的类型安全不依赖“别名”，而依赖不可隐式转换的类型声明。当业务存在明确语义边界（如版本、状态、租户、领域上下文），就应通过独立类建模——这是最轻量、最可靠、最符合语言设计哲学的解决方案。类型即文档，类型即约束，让错误在编译期发生，而非在生产环境崩溃。
立即学习“Java免费学习笔记（深入）”；
