方法重载是表达业务意图的语言机制，应统一命名、按场景分层设计、模拟默认参数，并在重载过多时转向策略+工厂模式。
方法重载本身不是“优化手段”，而是一种语言机制；它真正起作用的前提是——被有意识地用于表达业务意图，而非堆砌参数变体。用得好，能让调用方一眼看懂“想做什么”；用得乱，反而增加理解负担和维护成本。
用统一语义命名，让方法名说出业务目的
避免为不同参数组合生造多个名字（如 addInt、addDouble、addWithTax），而是保留一个清晰的业务动词，靠重载区分输入形态。
- 比如处理“创建订单”，可提供：
createOrder(Customer, Product)、createOrder(String customerId, String productId)、createOrder(OrderRequest request) - 所有方法都叫
createOrder，调用者无需记忆多个相似功能的方法名，只关注自己手头有什么数据 - 方法名不暴露技术细节（如类型），只表达业务动作，可读性自然提升
按业务场景分层设计重载，而非按技术类型罗列
不要只为“支持 int、long、double”就写三个重载，而要问：这些参数在业务中代表什么？是否对应真实使用场景？
- 例如支付金额，可重载为：
pay(BigDecimal amount)（精确金额）、pay(int cents)（整数分）、pay(String amountStr)（前端传入字符串） - 每个重载背后都有明确的上下文来源，不是为了“类型全覆盖”，而是覆盖常见入口渠道
- 这样扩展新场景时（如增加扫码支付 ID 入参），只需新增一个重载，不影响原有逻辑，也不需修改调用方代码
配合默认参数思维（通过重载模拟），减少必填项干扰
Java 不支持默认参数，但可用重载实现类似效果，把非核心参数逐步收拢到更全的版本中。
- 例如发送通知：
sendNotification(String content)→sendNotification(String content, String channel)→sendNotification(String content, String channel, boolean urgent) - 最简版本满足快速调用，完整版本保留控制力，中间版本平滑过渡
- 每个简版方法内部直接委托给完整版（
this.sendNotification(content, "sms", false)），逻辑集中，修改一处即生效
当重载变多时，及时转向策略+工厂模式
一旦同一方法出现 4 个以上重载，或参数组合开始交叉（如同时有 String + int 和 int + String），说明业务维度已超出单一方法能清晰承载的范围。
- 这时应提取共通逻辑到私有方法，或封装成独立策略类（如
NotificationStrategy） - 对外提供统一入口（如
notify(NotifyRequest request)），由工厂根据 request 类型分发 - 既保持调用简洁，又为未来新增渠道、规则、校验留出清晰扩展点，避免重载爆炸
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
