静态方法应仅用于无状态、可复用的辅助逻辑，如数据转换、参数预处理、常量计算和空值防护；不得用于涉及状态、事务、外部依赖或完整业务流程的场景，业务主干必须由实例方法承载。
静态方法在业务处理类中应严格限定为“无状态、可复用、与具体对象无关”的辅助逻辑，不能承担核心业务流程或状态管理职责。业务主干必须由实例方法承载，静态方法只作支撑。
静态方法适合做的事
它适用于那些不依赖任何对象状态、输入完全决定输出、且被多处复用的纯计算或转换逻辑：
- 数据格式转换：如 String to LocalDateTime、金额元转分、JSON 字符串校验
- 参数预处理：如 校验 ID 是否为空或非法格式、截断超长字符串并加省略号
- 常量计算：如 根据订单类型返回默认折扣率、计算分页起始索引
- 空值/边界防护：如 CollectionUtils.isEmpty()、ObjectUtils.defaultIfNull()
静态方法不该做的事
一旦涉及状态、上下文、事务、外部依赖或可变行为，就不该用静态方法：
- 调用数据库、HTTP 接口或消息队列——这些操作天然带上下文和副作用
- 修改传入对象的字段（如直接 set 属性）——破坏不可变契约，引发并发风险
- 依赖 Spring Bean（如 Autowired Service）——静态方法无法享受依赖注入
- 封装完整业务用例（如 “创建订单并扣库存并发通知”）——这属于有状态、多步骤、需事务保障的实例行为
业务类中静态与实例方法的协作模式
推荐将静态方法作为实例方法的“工具前置”，而非替代：
- 实例方法负责编排：协调领域对象、调用仓储、触发事件、管理事务
- 静态方法负责原子转换：把 DTO 转成 VO、把时间戳标准化、把枚举码转描述
- 例如：orderService.createOrder(request) 是实例方法；其中调用的 OrderConverter.toEntity(request) 可以是静态工具方法
命名与组织建议
避免在业务主类里堆砌大量静态方法，保持关注点分离：
- 通用转换逻辑 → 提取到独立的 XXXConverter 工具类（final + 私有构造）
- 业务规则判断（如“是否满足优惠条件”）→ 放入 XXXRule 类，用实例方法+依赖注入支持策略扩展
- 若某静态方法只被一个业务类使用，且逻辑简单，可保留在该类中，但需加注释说明其无状态性
- 禁止在接口中声明业务相关的静态方法——这会模糊类型契约，也阻碍测试与替换
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
