方法重载应以语义一致、参数具体、数量精简为原则：用明确业务类型替代object或泛型，封装多参数为对象，避免行为差异混淆职责，统一返回类型。
方法重载本身不是接口设计的终点，而是让同一语义的操作适配不同输入的手段。关键在于：不为重载而重载，而要让每个重载变体都自然、无歧义、可预期。
参数类型具体化，拒绝 Object 或泛型通配符
用明确的业务类型代替宽泛的父类或接口，能让调用者一眼看懂方法用途，也避免运行时类型判断和强制转换。
- ✅ 推荐：
save(User user)、save(Order order)、save(Invoice invoice) - ❌ 避免：
save(Object obj)或<t> save(T item)</t>（除非是通用工具类且有清晰上下文）
参数数量精简，优先用对象封装复杂入参
当某类操作需要多个关联参数（如分页查询的 page、size、sort、filter），不要靠重载堆砌 list(int page, int size)、list(int page, int size, String sort) 等组合。这会快速膨胀、难以维护。
- ✅ 推荐：定义
PageQuery类封装所有分页相关字段，统一提供list(PageQuery query) - ✅ 补充：若只有 1–2 个高频可选参数，可用 Builder 模式或带默认值的静态工厂方法，而非重载
命名与行为保持一致，不靠重载掩盖语义差异
重载方法必须做“同一件事”，只是输入形式不同。如果逻辑本质不同（比如一个查缓存、一个查数据库），应拆成不同方法名，而不是靠重载混淆职责。
- ✅ 合理：
parse(String json)和parse(InputStream input)—— 都是解析 JSON 字符串，只是数据源不同 - ❌ 危险：
load(String id)（查缓存）和load(String id, boolean forceRefresh)（绕过缓存）—— 这属于行为开关，更适合用单独方法loadFresh(String id)或配置对象
避免仅靠返回类型区分重载，也不混合协变返回
Java 不支持仅靠返回类型重载；若多个重载返回不同类型（如 int、long、Optional<integer></integer>），调用方容易因类型推断出错，IDE 提示也会混乱。
- ✅ 坚持统一返回类型，例如全部返回
Result<t></t>或Optional<t></t> - ✅ 若需兼容旧版，可用新方法名（如
findByIdOpt()替代findById()返回 null 的旧版），而不是重载
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
