本文介绍如何利用 java 的类型系统（而非仅靠命名约定）严格区分语义不同的两类列表（如 oldfoos 和 newfoos），从根本上防止传参错误，涵盖类继承设计、封装包装类、泛型增强等实用方案。
在 Java 中，仅靠变量名（如 oldFoos 与 newFoos）无法阻止编译时误传——List<Foo> 是同一类型，IDE 和编译器无法识别其业务语义差异。真正的类型安全需由编译器可验证的类型结构提供。以下是三种正交且生产可用的设计策略，按安全性与灵活性递进：
✅ 方案一：完全独立类型（最高安全性，零隐式转换）
当「旧版」与「新版」在业务逻辑中永远不可互换、不可共用方法时，应定义两个无继承关系的独立类：
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; }
}
// 编译器强制隔离：List<OldFoo> ≠ List<NewFoo>
class NewFooRunner {
public double runFoos(List<NewFoo> foos) { // 只接受 NewFoo 列表
return foos.stream().mapToDouble(f -> f.someNum).sum();
}
}⚠️ 注意：若需共享字段或行为，可通过组合（Composition）复用公共逻辑，而非继承——这更符合面向对象的松耦合原则。
✅ 方案二：共享抽象基类/接口（平衡安全性与复用性）
当两类对象部分场景需统一处理（如日志打印、序列化），但关键 API 必须区分时，引入共同父类型：
立即学习“Java免费学习笔记（深入）”；
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
interface Foo {} // 标记接口，无方法（或定义通用只读方法）
final class OldFoo implements Foo {
private final double someNum;
public OldFoo(double someNum) { this.someNum = someNum; }
}
final class NewFoo implements Foo {
private final double someNum;
public NewFoo(double someNum) { this.someNum = someNum; }
}
// 关键API仍保持类型专用
class NewFooRunner {
public double runFoos(List<NewFoo> foos) { ... }
}
// 通用工具类可接受任意 Foo
class FooUtils {
static void logAll(List<? extends Foo> foos) { ... } // 安全协变
}✅ 优势：runFoos() 仍拒绝 List<OldFoo>；而 logAll() 可复用，且不破坏类型安全。
✅ 方案三：类型包装器（Type Wrapper）——推荐用于已有类无法修改场景
若 Foo 是遗留类或第三方类无法重构，可采用「包装器模式」创建语义专属容器：
final class OldFoos {
private final List<Foo> list;
public OldFoos(List<Foo> list) { this.list = List.copyOf(list); }
public List<Foo> asList() { return list; } // 显式解包，强调意图
}
final class NewFoos {
private final List<Foo> list;
public NewFoos(List<Foo> list) { this.list = List.copyOf(list); }
public List<Foo> asList() { return list; }
}
class NewFooRunner {
public double runFoos(NewFoos foos) { // 参数类型即语义
return foos.asList().stream().mapToDouble(f -> f.someNum).sum();
}
}? 提示：为避免运行时误用，可在构造器中加入校验（如检查 Foo 实例是否携带版本标记），或使用 sealed 类（Java 17+）限制子类。
总结：选择依据
| 场景 | 推荐方案 | 关键判断 |
|---|---|---|
| OldFoo 与 NewFoo 永远不兼容 | 独立类（方案一） | 零隐式转换，编译期100%拦截 |
| 需部分通用操作 + 关键路径强隔离 | 共同接口 + 专用参数（方案二） | 用 ? extends CommonInterface 支持协变，用具体类型保证关键API安全 |
| 无法修改 Foo 类本身 | 包装器（方案三） | 将语义绑定到容器类型，成本低、见效快 |
最终，类型系统的本质不是增加复杂度，而是将业务约束编码为编译器可执行的契约——这比注释、文档或测试更早、更可靠地守住质量防线。
