方法签名设计应以可读性为先，命名须明确意图，重载仅用于同一抽象下的自然参数差异，需规避类型模糊、泛型擦除冲突及null/字面量歧义，并通过显式类型约束或私有封装提升调用自解释性。
方法签名设计的核心不是“让编译器能过”，而是“让人一眼看懂该调什么、为什么这么调”。命名和重载一旦配合不当，表面上代码能编译，实则埋下调用歧义、维护困惑和重构雷区。
命名优先于重载：用名字说清意图，而不是靠参数猜行为
重载不是替代命名的捷径。当出现 process(String) 和 process(List<String>) 时，调用方看到 process(data) 无法判断是处理单个标识符，还是批量上下文——这本质是职责模糊。更清晰的做法是：
- 改用语义明确的方法名：
processById(String id)与processBatch(List<String> ids) - 若逻辑高度相关且参数差异自然（如
load(int id)/load(String code)），保留重载，但确保两个入口代表同一抽象动作的不同获取方式 - 避免为“省一个词”而重载：比如
send(Message)和send(String)，不如写成sendMessage(Message)和sendText(String)
规避高风险重载组合：这些搭配最容易引发编译期或运行时困惑
有些参数类型组合在 Java 类型系统里边界模糊，编译器虽能选，但人很难预判结果：
-
基本类型与对应包装类混用：如
handle(int)和handle(Integer)。传5走前者，传Integer.valueOf(5)走后者；但传null直接报错“ambiguous” -
父类与子类参数并存：如
render(Object)和render(String)。虽然String版本更精确，但若后续新增render(CharSequence)，匹配顺序可能意外改变 -
泛型擦除后签名冲突：如
<T> List<T> parse()和List<String> parse()编译不通过——桥接方法会让字节码中实际存在两个parse()，但源码看似合理
让调用点自解释：通过目标类型约束 + 显式声明减少推理负担
方法引用（this::method）和 Lambda 是歧义高发场景。因为编译器必须反推“你到底想绑定哪个重载”，而它只能依赖函数式接口的形参类型：
立即学习“Java免费学习笔记（深入）”；
- 不要写
list.forEach(this::handle)，除非handle只有一个版本；否则明确类型：listOfStrings.forEach((String s) -> handle(s))或Consumer<String> h = this::handle - 对静态工具方法，优先用带类型前缀的名称，而非重载：
StringUtils.isBlank(String)和StringUtils.isBlank(CharSequence)容易在Predicate<CharSequence>上出问题，不如统一收口为StringUtils.isStringBlank(...)和StringUtils.isCharSequenceBlank(...) - 必要时用私有封装屏蔽重载细节：
public void handle(User user) { handleInternal(user); }，把真正重载的handleInternal设为private，对外只暴露单一语义入口
Null 和字面量是歧义放大器：设计时主动防御
Java 不允许在调用时显式标注参数类型，所以 null、整数字面量、字符字面量这类“类型不唯一”的输入，会直接暴露重载设计缺陷：
- 如果方法接受可为空的引用类型，就不要同时提供另一个同名方法接受另一不可空类型（如
f(String)+f(Integer)）——f(null)必然失败 - 字面量
'a'是char，97是int，但(char)97又回到char。与其依赖开发者记住这些规则，不如把字符处理单独命名：handleChar(char c)和handleCodePoint(int cp) - 对可变参数方法，明确它是兜底方案：
log(String msg, Object... args)应比log(String msg)和log(String msg, Throwable t)更宽泛，且文档注明“仅用于格式化日志，非主业务路径”
