静态类改造：选构造注入转普通类还是保留静态用方法注入？

优先推荐版本2的构造注入方案，除非受限于极端性能要求或历史代码强兼容场景。以下是两种方案的核心陷阱与选择逻辑：

一、保留静态类+方法注入（版本1）的陷阱 #

• 冗余传参与不一致风险：你的Mapper类已经通过构造注入持有Order实例，但getConstraint方法仍要求调用方传入Order，既造成代码冗余，还可能出现注入的Order和传入的Order不一致的情况，引发逻辑错误。
• 测试成本高：静态类的方法依赖外部参数时，单元测试每次调用都要手动构造或传入Order实例，无法通过依赖注入框架mock依赖，测试代码会变得繁琐且难以覆盖所有分支。
• 依赖不透明：静态方法的依赖隐藏在参数列表中，其他开发人员阅读代码时无法快速识别Util类的依赖关系，增加维护成本。
• 线程安全隐患：如果Order不是线程安全的对象，多线程调用静态方法时，外部传入的Order实例状态可能被并发修改，引发难以排查的问题。

仅当Util是纯无状态工具类（比如依赖的Order是常量类、无状态单例），且调用方天然持有该依赖时，才适合暂时保留这种方式。

二、转为普通类+构造注入（版本2）的优势与注意事项 #

核心优势 #

• 依赖关系明确：Util类通过构造方法声明依赖Order，代码可读性强，符合依赖倒置原则，其他开发人员能快速知晓类的依赖结构。
• 可测试性优异：单元测试时可以轻松注入Mock的Order实例，快速覆盖X=true和X=false的分支逻辑，无需每次调用都手动传参。
• 消除冗余传参：Mapper类只需注入Util实例（注：版本2的Mapper代码缺少Util注入，需补充private final Util util;并在构造方法注入），调用时无需传递Order，减少出错概率。
• 线程安全可控：如果Order是线程安全的单例，Util作为单例类可直接复用；如果Order是多实例，也可通过DI框架管理其生命周期，避免并发问题。

需注意的陷阱 #

• 避免职责膨胀：不要为了构造注入而添加无关依赖，保持Util类的单一职责——仅负责isFeasible的逻辑判断，不要额外承担其他业务逻辑。
• 生命周期匹配：确保Util和Order的生命周期一致（比如同为单例），若Order是原型类，需确认DI框架是否支持这种依赖组合，避免出现实例复用异常。
• 代码补全：版本2的Mapper类缺少对Util的注入，需补充后才能正常调用util.isFeasible(ex)，否则代码无法编译。

三、针对你的场景的具体建议 #

你的Util类已经需要依赖Order做分支逻辑判断，说明它不再是纯无状态工具类，转为普通类使用构造注入是更合理的选择：

• 版本1的冗余传参设计完全没有必要，反而增加出错风险；
• 版本2的结构更符合面向对象设计原则，后续的维护、测试成本更低。

内容的提问来源于stack exchange，提问作者kiran