Java单例模式获取JWT Token：两种实现方案孰优孰劣？

方案一：外部注入Token的单例实现 #

仅在getInstance()中创建单例实例，由外部调用认证服务后通过setter注入Token。

优势 #

• 职责单一：JWTSingleton只专注于Token的持有与提供，把Token获取逻辑剥离到外部，完全符合单一职责原则
• 测试友好：单元测试时无需依赖真实认证服务，直接通过setter注入模拟Token即可完成测试，成本极低
• 灵活扩展：Token的刷新、重试、认证服务切换等逻辑都可以在外部处理，不用修改单例类本身，后续迭代更顺畅

劣势 #

• 外部耦合提升：调用方需要额外处理Token的获取逻辑，若多个地方使用可能出现重复代码（可通过封装专门的认证服务类解决）
• 空值风险：如果外部忘记注入Token，使用时会触发空指针，需要在单例类中增加Token非空校验逻辑

方案二：内部集成Token获取的单例实现 #

保留当前在getInstance()内部调用认证服务获取Token的逻辑。

优势 #

• 使用便捷：调用方只需调用getInstance()就能直接拿到可用的Token实例，无需额外操作
• 封装性强：Token获取的细节完全隐藏在单例内部，外部无需关心认证服务的调用逻辑

劣势 #

• 职责混杂：单例类既要负责自身实例化，又要处理认证服务调用，违反单一职责原则，代码耦合度高
• 测试困难：单元测试时无法绕过真实的认证服务调用，要么依赖外部服务可用，要么需要复杂的mock才能完成测试
• 扩展性差：后续若要修改认证方式、增加Token刷新机制，必须修改单例类代码，违反开闭原则
• 初始化风险：getInstance()时同步调用认证服务，若服务不可用，会直接导致单例初始化失败，影响所有依赖该类的功能

结论 #

方案一更符合软件开发的最佳实践。虽然它要求外部处理Token获取，但可以通过封装专门的AuthService类统一处理认证逻辑，既避免重复代码，又保持JWTSingleton的职责清晰。这种拆分方式不仅提升了代码的可维护性和可测试性，也为后续功能扩展留出了足够空间。

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