Swift中全局变量的替代方案：Form A与Form B的差异及更优实现方式探讨

嘿，针对你的问题，我来一步步拆解清楚：

Form A 和 Form B 的核心差异 #

首先得明确：这两种形式本质上都是全局可访问的单例，但它们在实例安全性上有显著区别：

• Form A：你用了全局可变变量 var app = Global()，这意味着任何代码都能随时重新赋值（比如 app = Global()），直接替换掉原有的实例，导致之前存储的状态全部丢失——这是个严重的隐患，也是SonarQube大概率会重点吐槽的点之一。
• Form B：采用了static let+私有初始化的标准单例模式，保证了全局只有一个不可变的实例，不会被意外替换。这种写法比Form A更严谨，避免了实例被篡改的风险，但本质上还是全局访问的单例。

所以结论是：Form B比Form A更安全，但两者都逃不开全局状态带来的代码异味——SonarQube的检测结果对两者都适用。

为什么全局单例会被标记为代码异味？ #

SonarQube揪的是全局单例的这些痛点：

• 耦合度极高：所有调用app.logout()或Global.app.logout()的代码，都直接依赖这个全局实例。一旦你要修改Global类的逻辑，所有调用点都可能受影响，维护成本飙升。
• 测试难度大：单元测试时，你没办法轻易把全局的app换成Mock实例，只能用真实的服务逻辑，导致测试不灵活，甚至无法隔离测试。
• 隐藏依赖：代码里直接调用全局方法，阅读者看不到这个依赖是从哪来的，增加了理解成本，也容易导致隐式的Bug。

如果你偏好类似Form A的写法，怎么缓解异味？ #

如果暂时不想彻底重构，至少先把Form A的可变变量改成不可变常量：

// 把var改成let，避免实例被意外替换
let app = Global()
class Global { }

这能解决实例被篡改的风险，但还是没解决全局访问的根本问题——耦合和测试困难的问题依然存在，SonarQube可能还是会标记。

更优的实现方案：依赖注入+拆分服务 #

从长远来看，**依赖注入（DI）**是解决这类问题的标准方案，搭配单一职责原则，能从根源上消除全局单例的异味：

第一步：拆分大而全的Global类 #

把原来塞在Global里的功能拆分成多个职责单一的服务类，比如：

// 负责登录登出的服务
class AuthService {
    func logout() { /* 具体实现 */ }
}

// 负责相机操作的服务
class CameraService {
    func doSomething() { /* 具体实现 */ }
}

// 负责埋点统计的服务
class AnalyticsService {
    func logEvent(_ event: EventType) { /* 具体实现 */ }
}

这样每个服务只做一件事，代码更清晰，也更容易维护和测试。

第二步：用依赖注入传递服务实例 #

不再让代码直接访问全局实例，而是把需要的服务通过初始化参数、属性或方法参数传递给需要的对象。比如某个ViewController需要登出功能：

class MyViewController: UIViewController {
    // 明确声明依赖的服务
    private let authService: AuthService
    
    // 通过初始化方法注入依赖
    init(authService: AuthService) {
        self.authService = authService
        super.init(nibName: nil, bundle: nil)
    }
    
    // 调用服务的方法
    @objc func handleLogoutTap() {
        authService.logout()
    }
}

// 使用时创建服务实例并注入
let authService = AuthService()
let vc = MyViewController(authService: authService)

依赖注入的好处 #

• 降低耦合：ViewController只依赖AuthService的接口（如果定义协议的话，还能进一步解耦），不依赖全局状态，修改服务实现不会影响调用方。
• 易于测试：单元测试时可以传入Mock版的AuthService，模拟登出的行为，轻松验证逻辑是否正确。
• 明确依赖：从初始化参数就能清楚看到ViewController需要哪些服务，代码可读性大幅提升。

如果项目规模较大，手动写DI觉得繁琐，可以考虑用DI框架（比如Swinject）来简化，但小型项目手动DI完全足够。

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