Java方法重载应以业务语义为核心，按类型区分（如sendNotification(EmailUser)）、按粒度控制参数数量（避免布尔爆炸）、慎用顺序重载，并延伸至构造器与Builder模式。
Java 中方法重载不是为了“凑数量”，而是让同一语义的操作能自然适配不同输入场景。关键不在能不能重载，而在是否该重载、怎么重载才真正支撑业务变化。
按业务维度区分参数类型
当业务逻辑本质相同但处理对象不同（如用户、订单、商品），优先用具体类型而非 Object 或泛型擦除后的原始类型。例如：
- 推荐：`sendNotification(EmailUser user)`、`sendNotification(SmsUser user)` —— 编译期可判别，语义清晰，后续扩展新通知渠道时不易冲突
- 不推荐：`sendNotification(Object obj)` + instanceof 判断 —— 运行时才识别，易漏分支，难测试，违反开闭原则
按输入粒度控制参数个数
业务中常有“基础版”和“增强版”调用需求。用参数数量差异表达能力层级，比堆砌 boolean 标志位更直观：
- `createOrder(String productId, int quantity)` —— 默认走主仓库、标准时效
- `createOrder(String productId, int quantity, String warehouseId, DeliverySpeed speed)` —— 显式指定履约细节
避免出现 `createOrder(..., boolean usePriority, boolean skipValidation, boolean forceSync)` 这类标志爆炸式签名，它会让调用方每次都要查文档。
谨慎使用参数顺序重载
仅当类型组合天然存在业务对称性时才用顺序区分，比如字符串拼接或单位换算：
- `formatAmount(BigDecimal amount, String currency)` 和 `formatAmount(String currency, BigDecimal amount)` —— 若业务中两种写法都高频且无歧义，可接受
- 但 `process(String id, Date date)` 和 `process(Date date, String id)` 就容易引发误调，编译器无法提示语义错误，应禁用
配合构造器与 Builder 模式延伸重载价值
重载不只是普通方法的事。构造器重载直接决定对象创建的业务入口是否友好：
- 提供 `new ReportRequest(LocalDate start, LocalDate end)` 和 `new ReportRequest(String reportType, Map
filters)` 两种初始化路径，对应运营后台和 API 接入两类典型场景 - 复杂对象建议用 Builder，但 Builder 的 `build()` 方法本身也可重载，例如 `build()` 返回默认报表，`build(ExportFormat format)` 返回导出结构体
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
