Java方法重载有效，但仅依据参数类型、数量、顺序判断，返回类型、泛型实际类型、异常声明等不参与；null调用可能引发歧义，自动类型提升或泛型擦除亦需谨慎处理。
Java方法重载（Overloading）本身是有效且被广泛使用的语言特性，所谓“无效探究”通常源于对重载规则的误解或错误实践，并非重载机制本身失效。关键在于：重载是否生效，取决于编译期能否根据**参数类型、数量、顺序**明确区分同名方法；而返回类型、访问修饰符、异常声明等**不参与重载判断**。
重载只看参数列表，和返回值无关
很多初学者误以为改变返回类型就能构成重载，这是常见误区。Java编译器在解析方法调用时，完全不考虑返回值类型。
- 以下两个方法无法共存，编译报错：Duplicate method print(String) in type Demo
void print(String s) { }
String print(String s) { return s; }
解决办法：必须改变参数列表——比如加一个 int 参数，或把 String 改成 Object，或调整参数顺序（如 (String, int) vs (int, String)）。
自动类型提升可能引发意料外的重载匹配
当传入实参与多个重载方法的形参不完全匹配时，Java会按优先级尝试隐式转换（如 byte → short → int → long → float → double），这可能导致调用到并非预期的方法。
立即学习“Java免费学习笔记（深入）”；
- 定义了 void show(int x) 和 void show(double x)
- 调用 show(5) → 匹配 int 版本（精确匹配优先）
- 但调用 show(5L) → 匹配 double 版本（long → double 是合法提升，而 long → int 不合法）
建议：对关键业务逻辑，避免依赖自动提升；必要时显式强制类型转换，或增加更精确的重载版本（如 show(long x)）。
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
泛型擦除让基于类型参数的重载失效
由于泛型在运行时被擦除，List
void process(List
void process(List
原因：擦除后两个方法签名都变成 process(List list)，属于重复声明。若需区分，应改用不同参数类型（如 List 与 Set）、添加辅助参数，或用 instanceof + 类型转换在运行时处理。
null 值调用时的重载选择可能模糊
当多个重载方法接受不同引用类型，且传入 null 时，编译器会选择“最具体”的类型。但如果存在多个同样具体的类型（如两个无继承关系的类），就会编译失败。
- 有 void test(String s) 和 void test(Integer i)，调用 test(null) → 编译错误：ambiguous
- 但若有 void test(Object o)、void test(String s)，则 test(null) 明确匹配 String（更具体）
建议：避免让 null 成为重载决策的关键输入；如需支持 null，可统一用 Object 参数 + 内部 instanceof 判断，或明确设计默认行为。
基本上就这些。重载不是无效，而是有严格边界——它发生在编译期，只认参数签名，不看语义、不看返回值、不看泛型实际类型。用对了，清晰又灵活；用错了，就变成“看似重载，实则冲突”。
