Java中基本类型与包装类不可仅凭类型不同安全重载，易因null、字面量或泛型擦除引发歧义；应采用语义化命名、显式类型转换或提取通用方法来明确意图、规避风险。
Java 中基本类型（如 int）和对应包装类（如 Integer）不能靠“仅类型不同”来安全重载——编译器在匹配时容易陷入歧义，尤其遇到 null、字面量或泛型擦除场景。关键不是强行保留同名方法，而是让调用意图清晰、类型边界可分辨。
别用 int 和 Integer 同时重载一个方法名
这是最常见也最危险的做法。例如：
-
void handle(int id)和void handle(Integer id)共存 - 调用
handle(123)→ 走int版本（没问题） - 调用
handle(null)→ 编译报错 “ambiguous method call”（null可匹配Integer，也可向上转型为Object，若还有handle(Object)就彻底无法抉择）
用语义化命名替代模糊重载
把“类型差异”转化为“业务意图差异”，既避免歧义，又提升可读性：
- 把
save(int id)和save(Integer id)拆成：saveById(int id)（明确是有效非空 ID）saveByOptionalId(Integer id)（强调可能为空） - 处理集合时，不用
process(List和) process(List（泛型擦除后签名重复，直接编译失败），而用：) processUserNames(Listnames) processOrderIds(Listids) - 若逻辑高度复用，提取通用私有方法：
private，对外只暴露语义明确的公有入口void doProcess(List list, Function formatter)
必须保留重载时，用显式转换控制编译期类型
当历史代码难以重构，最小改动破局：
- 对
null实参：写成handle((Integer) null)或handle((String) null)，强制指定目标类型 - 对字面量：避免
handle(42)这种模糊调用，改用handle(Integer.valueOf(42))或handle((int) 42) - 在 Lambda 或方法引用中锚定类型：
不写list.forEach(this::handle)，而写list.forEach((Integer x) -> this.handle(x))
警惕自动装箱/拆箱引发的静默问题
歧义不止在编译期，运行期也可能因隐式转换掩盖业务状态：
-
if (user.getAge() > 18)：若getAge()返回Integer且为null，会触发NullPointerException - 若返回的是
int，未赋值时默认为0，条件恒为false，但你根本不知道这个年龄是“缺失”还是“零岁” - 涉及比较或判空，优先用
Objects.equals(a, b)或显式检查：age != null && age > 18
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
