方法重载隐患在于类型模糊、null安全与可维护性冲突，评审需聚焦调用明确性、参数易混淆性及语义一致性，尤其警惕隐式转换引发的NPE和新增重载破坏原有行为。
方法重载本身不是问题，但当它与类型模糊、null 安全、可维护性冲突时，就容易埋下隐患。代码评审中不靠猜，而是看三点：调用是否明确、参数是否易混淆、新增方法是否破坏原有语义。
看调用处是否依赖隐式类型转换
评审时重点检查调用方传入的实参类型是否“刚好卡在多个重载版本的边界上”。比如：
- 传 int 却同时存在
process(int)和process(Integer)—— 编译器选前者，但若某天 int 值为 null（如从 Optional.orElse(null) 得来），实际运行会触发自动装箱失败，抛 NPE - 传 String 却有
handle(String)和handle(Object)—— 看似安全，但若后续新增handle(CharSequence)，编译器可能切换目标，行为悄然改变
查新增重载是否引入歧义或隐藏空指针风险
特别警惕在已有方法基础上“补一个 String 版本”这类操作。例如：
- 原只有
validate(OrderDTO)，后来加了validate(String json) - 而调用处是
validate(dto == null ? null : dto.toJson())—— 表面逻辑成立，但一旦 dto 为 null，就会走入 String 版本，而该版本内部未做 null 检查，直接调用 json.length() 就崩 - 这种问题在单元测试里容易漏掉（因为通常只测非 null 场景），必须在 CR 时人工推演 null 路径
核对重载方法的行为一致性
重载方法名相同，用户天然预期行为相似。若违反，就是设计裂缝：
立即学习“Java免费学习笔记（深入）”；
-
save(User)同步写库，save(List<User>)却走异步队列 —— 名称没区分，语义却分裂 -
parse(String)返回 null 表示失败，parse(Reader)却抛异常 —— 错误处理风格不统一，调用方难以适配 - 评审时直接问：“如果我把参数类型改一下，业务含义和错误策略会变吗？” 答案要是“不会”，才算过关
真正有效的 CR 不是数重载有几个，而是站在调用方视角，确认每次调用都能一眼看懂走的是哪条路、null 怎么处理、失败怎么反馈。工具如 FindBugs 或 SpotBugs 能标出“可能的空指针传播路径”，但是否构成风险，得靠人结合上下文判断。
