Java编译器按静态类型和实参字面量在编译期确定重载方法，分三步匹配：精确匹配→装箱/拆箱→可变参数；null传参会因多引用类型精确匹配而报歧义错误。
方法重载时编译器怎么选函数
Java 编译器不靠运行时类型、不看返回值，只根据 static 类型和实参字面量（或强制转换后的类型）在编译期锁死调用哪个重载版本。匹配分三步：精确匹配 → 自动装箱/拆箱 → 可变参数。一旦某步找到唯一候选，就停止往下走。
- 如果两个重载都满足当前步骤（比如都有
Object和String版本，传null），编译直接报错：reference to xxx is ambiguous - 基本类型字面量优先匹配对应包装类（如
1会倾向Integer而非Object），但1L就只匹配Long或long - 泛型方法不参与重载解析——
<t> void f(T)</t>和void f(String)共存时，传"a"一定选后者
为什么传 null 会触发歧义错误
null 没有类型，它能合法赋给任何引用类型，所以当多个重载参数都是引用类型（比如 f(String)、f(List)、f(File)）时，编译器无法判断你“本意”想调哪个——三者都满足第一阶段“精确匹配”，于是拒绝编译。
- 解决办法只有显式转型：
f((String) null)或f((List) null) - 如果其中一个是基本类型参数（如
f(int)），null根本不匹配，不会歧义；但若写成f(Integer)，又回到歧义场景 - IDE 常高亮提示，但错误实际发生在 javac 阶段，不是运行时报错
自动装箱让重载更危险
看似安全的数字字面量，可能因装箱规则意外掉进陷阱。比如同时存在 foo(int) 和 foo(Integer)，传 42 会选前者；但加个 final 或从变量读取，就可能触发装箱路径。
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
-
int x = 42; foo(x);→ 匹配foo(int) -
final Integer y = 42; foo(y);→ 匹配foo(Integer) -
Number z = 42; foo(z);→ 编译失败，因为Number既不精确匹配int也不匹配Integer（需拆箱但不确定目标类型） - 避免混用基本类型和包装类参数的重载，尤其不要只为“支持 null”而加一个
foo(Integer)
可变参数是最后兜底选项
foo(String...) 不是“能接受任意多 String”，而是“只在前面所有重载都不匹配时才启用”。它优先级最低，且一旦启用，就不再考虑其他重载。
立即学习“Java免费学习笔记（深入）”；
-
foo(String)和foo(String...)共存时，foo("a")永远走前者；只有foo("a", "b")才触发后者 - 但如果还定义了
foo(Object...)，那么传foo(1, "x")会直接匹配它（因为int和String都能转Object），跳过所有更具体的重载 - 可变参数 + 泛型（如
<t> foo(T...)</t>）会进一步模糊类型推导，容易引发意外匹配
最常被忽略的是：重载解析完全静态，和子类方法、接口默认方法、甚至 @Override 都无关。哪怕你在子类里重写了某个重载，父类引用调用时仍按父类声明类型解析——这点在设计 API 时稍不注意，就会让使用者掉坑里。
