方法重载需防范编译期静态绑定导致的隐性行为切换：避免基本类型与包装类型、string与object等歧义签名；慎用varargs；运行时类型分发应依赖重写或visitor模式；构造函数重载宜用builder或静态工厂统一初始化。
方法重载本身不是问题，问题出在编译期静态绑定与运行时行为之间的错位。实际开发中真正要防的，是“看起来调用了A，其实执行了B”这类隐性切换。
避免参数类型模糊导致误匹配
基本类型和包装类型、String 和 CharSequence、子类和父类参数混用时，编译器可能选中你没预料到的重载版本。比如：
- 不要同时定义 void handle(int) 和 void handle(Integer) —— 传入
1会走 int 版，传入null却可能触发自动拆箱异常 - 避免 void process(String) 和 void process(Object) 并存 —— 传入
null时，编译器无法确定该选哪个，直接编译报错 - 若需支持多种输入，优先用泛型或统一抽象类型（如用 CharSequence 替代 String + StringBuilder）
警惕可变参数（varargs）的低优先级陷阱
varargs 是重载解析的“兜底选项”，只有当其他所有精确匹配都失败时才启用。它容易掩盖逻辑歧义：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 定义了 void log(String msg) 和 void log(String... msgs)，调用
log("error")会走前者；但log((String) null)反而触发后者，造成空数组传入 - 如果业务上确实需要多参数日志，建议改用明确签名，例如 void log(String level, String msg) 或封装为 LogEntry 对象
不依赖重载做运行时类型分发
重载在编译期就决定了调用目标，和对象实际类型无关。想按真实类型执行不同逻辑，应该用重写（override）或 visitor 模式：
- 错误做法：在同一个类里写 void print(List>)、void print(Set>)、void print(Map,>) —— 若变量声明为
Collection>，三个都不会被选中，只会匹配更宽泛的print(Object) - 正确做法：把逻辑移到各自集合类型的实现类中，通过多态调用；或使用
instanceof显式判断（适合简单场景）
构造函数重载要控制初始化路径
构造函数重载常见问题是参数膨胀和默认值散落，易引发状态不一致：
- 避免出现 5 个以上构造函数。优先用“构造函数 + Builder 模式”或“静态工厂方法”替代
- 所有构造函数应尽快委托给一个主构造函数（使用
this(...)），确保初始化逻辑集中，不会漏掉字段赋值或校验 - 对可能为 null 的参数，在构造函数内尽早检查并抛出
IllegalArgumentException，而不是留到后续方法里触发 NPE
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
