方法签名是jvm字节码中由方法名加擦除后参数类型描述符（如(ljava/util/list;)v）构成的唯一标识，不包含返回值、泛型等；重载冲突常源于描述符相同或调用时匹配模糊。
方法签名不是“方法名加参数个数”这种粗略印象，而是 JVM 字节码层面严格识别的唯一标识：**方法名 + 参数类型的擦除后形式（精确到每个类型在字节码中的描述符）**。它不包含返回值、异常、修饰符、参数名，也不保留泛型类型参数。理解这一点，才能真正避开重载冲突。
看清签名本质：JVM 只认 descriptor
编译后，JVM 通过类似 (Ljava/util/List;)V 这样的符号引用定位方法。括号内是参数描述符，括号外是方法名。例如：
-
void handle(List<string>)</string>和void handle(List<integer>)</integer>擦除后都是(Ljava/util/List;)V→ 冲突，编译失败 -
void run(int)和void run(Integer)分别对应(I)V和(Ljava/lang/Integer;)V→ 签名不同，可共存，但传null会报 ambiguous reference -
void test(String)和void test(CharSequence)擦除后是(Ljava/lang/String;)V和(Ljava/lang/CharSequence;)V→ 是两个签名，但因String实现CharSequence，调用点可能模糊
避开高频歧义组合
有些重载看似合理，实则埋下调用雷区：
- 基本类型与包装类并存（
handle(int)/handle(Integer)）：自动装箱规则让handle(5)走int，handle(null)直接编译失败 - 父类与子类参数混搭（
render(Object)/render(String)）：新增render(CharSequence)后，匹配优先级可能变化，行为意外迁移 - 仅靠隐式类型提升区分（
handle(short)/handle(long)）：传字面量1时无唯一最精确匹配，编译失败
用命名代替模糊重载
当参数差异不能自然体现意图，就该换名字，而不是硬塞进同一个方法名里：
- ❌
process(List<string>)</string>和process(List<integer>)</integer> - ✅
processUserNames(List<string>)</string>和processUserIds(List<integer>)</integer> - ❌
send(Message)和send(String) - ✅
sendMessage(Message)和sendText(String)
职责清晰了，调用方一眼看懂，也不用猜编译器选了哪个版本。
方法引用场景要显式约束类型
写 list.forEach(this::handle) 时，如果 handle 有多个重载，编译器无法从 Consumer<object></object> 推出具体目标：
- 改用带类型声明的变量：
Consumer<string> h = this::handle;</string> - 或直接用 Lambda：
listOfString.forEach(s -> this.handle(s)); - 静态工具方法尽量避免重载，如
StringUtils.isBlank(String)和isBlank(CharSequence)容易在函数式上下文中失效，不如统一为isStringBlank()和isCharSequenceBlank()
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
