Java方法重载不考虑返回类型，仅依据方法名和参数列表（个数、类型、顺序）判断；void foo()与int foo()在同个类中非法共存，编译直接报错。
Java方法重载不看返回类型
不行，void foo() 和 int foo() 在同一个类里不能共存——编译器直接报错，不是运行时问题，是语法层面被禁止的。
Java只根据方法名 + 参数列表（参数个数、类型、顺序）判断是否构成重载。返回类型不参与签名计算，JVM字节码里也根本不靠它区分方法。
- 常见错误现象：
error: method xxx() is already defined in class YYY - 哪怕两个方法返回类型不同、参数完全一样，也会触发这个编译错误
- 泛型擦除后可能更隐蔽：比如
List<string> getData()</string>和List<integer> getData()</integer>，擦除后都是List getData()，照样冲突
为什么设计成这样？
因为调用方不写返回类型，编译器无法靠它反推该选哪个方法。
比如你写了 foo()，编译器得立刻决定调哪个重载版本；但如果你没把返回值赋给变量、也没用在表达式里，它根本不知道你“想要”什么类型。
Java注释规范Skills
下载
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
立即学习“Java免费学习笔记（深入）”；
- 场景举例：仅写一句
getData();，编译器无法从上下文判断该选String getData()还是int getData() - 如果允许按返回类型重载，就等于把类型推导压力甩给编译器，且容易导致歧义和不可预测行为
- 对比Kotlin：它支持类似功能，但依赖完整的上下文推导（比如赋值目标类型），而Java选择更保守、更明确的规则
怎么绕过这个限制？
不能改返回类型来重载，但可以改参数——哪怕加个无意义的标记参数，也能合法区分。
- 最常用：加一个
Class<t></t>参数，比如<t> T get(Class<t> type)</t></t>，靠传入String.class或Integer.class区分逻辑 - 或者用 builder 模式：把返回类型决策推迟到链式调用末尾，比如
query().as(String.class) - 避免用
Object返回再强转——这会把类型检查推到运行时，丢失编译期安全
容易被忽略的坑
很多人以为“重载 = 多个同名方法”，结果在重构时删掉一个参数、只改了返回类型，就意外破坏了重载关系。
- IDE 有时不会高亮警告，但编译失败才暴露问题
- 子类重写父类方法时，如果只改了返回类型（且是协变返回类型），那是重写（override），不是重载（overload）——别混这两件事
- 反射调用
getDeclaredMethod("xxx", ...)时，必须传对参数类型数组，返回类型完全不影响查找结果
真正要区分行为，得从参数设计入手，而不是盯着返回类型打转。
