重构目标是将static工具类转为有职责、可组合、易替换的对象协作体系，核心是识别隐含上下文、提取可变点、用接口和依赖注入解耦，按业务能力建模、策略模式替代条件分支、依赖注入实现灵活组合。
直接把 static 公共类“砍开”不是目的，关键是让代码从“一堆工具函数集合”变成“有职责、可组合、易替换”的对象协作体系。核心思路是识别隐含的上下文、提取可变点、用接口和依赖注入解耦。
识别并封装隐含状态与上下文
static 工具类看似无状态，实际常依赖隐式环境（如当前用户、配置、时间、HTTP 请求上下文）。这些就是重构的突破口。
- 把“获取当前租户 ID”这种逻辑，抽成 TenantContext 类，提供
getCurrent()方法，底层可从 ThreadLocal、Spring Security Context 或请求头读取 - 把“格式化金额”从
StringUtils.formatMoney(double)拆为 MoneyFormatter，它持有Locale和Currency实例，支持不同地区/币种策略 - 原来
FileUtil.write(String path, String content)隐含了文件系统类型（本地/MinIO/S3），现在定义 FileStorage 接口，由LocalFileStorage、AliyunOssStorage实现
按业务能力划分领域服务类，而非功能切片
别再按“String 工具”“Date 工具”“Http 工具”分包。按谁在用、为什么用、变化原因是什么来建模。
- 订单导出功能频繁修改模板和输出格式？提取 OrderExportService，它内部组合
TemplateEngine、ExcelWriter、NotificationService，而不是塞进一个ExportUtil - 登录后要发欢迎邮件、记录行为、刷新 token？建 LoginOrchestrator 协调
EmailSender、AuditLogger、TokenManager，每个组件可独立测试和替换 - 原
JsonUtil.toJson(obj)被各处乱用？改为注入 JsonSerializer，实现类可基于 Jackson、Gson 或自定义序列化规则（如脱敏字段自动忽略）
用策略+工厂替代条件分支，让弹性可配置
static 方法里常见 if (type == A) {...} else if (type == B) {...} —— 这正是多态该出场的地方。
- 定义 PaymentProcessor 接口，有
process(PaymentRequest)方法 - 实现
AlipayProcessor、WechatPayProcessor、BankTransferProcessor - 用 PaymentProcessorFactory 根据支付渠道 code 返回对应实例；工厂本身可被 Spring 管理，支持运行时动态注册新渠道
- 原来
PayUtil.process(String channel, ...)彻底消失，调用方只依赖接口，完全不感知具体实现
依赖注入代替硬编码，让组合自由发生
拆完类之后，如果还靠 new XxxService() 或静态调用，就白拆了。必须交由容器管理生命周期和依赖关系。
- 所有新服务类加
@Service或@Component，构造函数声明所需依赖（如OrderExportService(FileStorage storage, TemplateEngine engine)） - 避免在类中调用
ApplicationContext.getBean()—— 这是反模式，说明依赖没理清 - 对需要运行时选择的场景（如根据用户等级用不同风控策略），用
@Qualifier+ 命名 Bean，或引入 StrategyRegistry 手动注册映射关系
重构不是一次重写，而是小步验证：先抽一个最痛的 static 方法 → 封装为对象 → 注入使用 → 删除旧调用。每步都能跑通，弹性就自然长出来了。
