Java方法重载判定发生在编译期，仅依据实参静态类型与方法签名匹配；基础类型自动提升仅在无精确匹配时参与候选筛选，不改变重载判定逻辑，优先级为：精确匹配＞宽化提升＞装箱/拆箱＞可变参数。
基础类型自动提升不影响重载判定时机
Java 的方法重载解析发生在编译期，完全基于实参的**静态类型**和方法签名匹配，而不是运行时实际值或隐式转换后的类型。基础类型自动提升（如 byte → short → int → long → float → double）只在**没有精确匹配时才参与候选筛选**，但它不改变“是否构成重载”的判断逻辑，也不导致方法签名等效。
重载匹配优先级：精确匹配 > 宽化提升 > 装箱/拆箱 > 可变参数
编译器选方法时按固定顺序尝试匹配：
-
第一步：找参数类型完全一致的方法（例如传
int就优先匹配void foo(int)） -
第二步：若无完全匹配，尝试基础类型宽化（widening），比如传
byte会考虑foo(int)、foo(long)，但不会考虑foo(short)（因为 short 不是 byte 的直接宽化目标，且 short 和 byte 都是 16 位，无明确方向） -
第三步：仍无匹配，才考虑装箱（如 int → Integer）或拆箱，但注意：
foo(Integer)和foo(int)是两个独立重载，互不干扰 -
第四步：最后才 fallback 到 varargs 方法，比如
foo(int...)是兜底选项，仅当其他路径都失败时启用
容易踩坑的典型场景
以下情况看似合理，实则编译报错或行为反直觉：
- 定义了
void handle(int)和void handle(long)，再传short s = 10;→ 编译器选handle(int)（short 宽化到 int 是最窄可行路径），不是 long - 只有
handle(float)和handle(double)，传int 5→ 编译通过（int 可宽化到两者），但若两者都存在，编译器会报错“ambiguous”，因为 int→float 和 int→double 都是合法宽化，且无优先级差异 - 传
null给foo(String)和foo(Integer)→ 编译失败，因为 null 对两者都“同样适用”，无法选出最具体版本 - 写
foo(int)和foo(Integer)同时存在 → 合法重载；但传字面量5永远走int版本，不会自动装箱去调用Integer版本
构造器和普通方法遵循同一套规则
构造器重载完全复用方法重载机制。例如：
立即学习“Java免费学习笔记（深入）”；
-
new Person(String name)和new Person(int age)是有效重载 -
new Person(byte b)传100字面量 → 匹配Person(byte)；传200→ 编译失败（超出 byte 范围），但若只有Person(int)，则自动宽化成功 - 多个构造器共存时，
this(...)调用也必须满足重载解析规则，不能依赖运行时类型推断
