作为 iOS 开发者，你在日常编码中肯定频繁接触过系统提供的全局访问点，比如 INLINECODE0d06cd4a 来保存配置，或者 INLINECODE93617899 来管理应用生命周期。你是否想过这些类为什么能在任何地方被直接调用，且始终保持数据同步？这背后就是单例模式在起作用。
在这篇文章中，我们将深入探讨 Swift 中的单例模式。我们将一起揭开它的神秘面纱，学习如何创建一个线程安全的单例，探讨它的实际应用场景，以及在使用它时需要注意的坑和优化技巧。无论你是初学者还是希望巩固基础的开发者，这篇文章都将帮助你更专业地掌握这一重要的设计模式。
什么是单例模式？
单例模式是一种创建型设计模式，它的核心思想非常简单：确保一个类在整个应用程序的生命周期中只有一个实例存在，并且提供一个全局的访问点来获取该实例。
你可以把它想象成应用程序的“管家”。家里不需要十个管家乱指挥，只需要一个经验丰富的管家来统筹安排所有事情。当你需要安排任务时（调用方法），你只需要找到这个唯一的管家即可。
#### 单例的优缺点
在开始写代码之前，我们需要先权衡一下利弊。虽然单例非常流行，但它并不总是银弹。
优点：
- 延迟初始化： 单例实例通常在第一次被访问时才创建，这有助于减少应用启动时的内存开销。
- 全局访问： 它为我们提供了一个随处可见的访问点，避免了在不同层级间繁琐地传递对象引用。
- 状态共享： 非常适合管理那些需要在整个应用中共享的状态，例如用户登录信息、网络配置或全局的样式设置。
缺点：
- 隐藏的依赖关系： 当你的代码大量依赖单例时，类与类之间的耦合度会变得隐晦而紧密。你很难一眼看出某个函数到底依赖了哪些全局状态。
- 测试困难： 由于单例在整个应用运行期间持久存在，它的状态会污染测试用例。如果不小心，上一个测试的数据可能会影响下一个测试的结果。
- 并发问题： 如果单例内部包含可变状态，在多线程环境下如果不加控制，可能会导致数据竞争。
尽管存在这些争议，但在 Apple 的生态系统中，单例依然占据着重要的地位（如 INLINECODE0b69749a, INLINECODE8d920961 等）。关键在于我们如何正确地使用它。
Swift 中实现单例的核心步骤
在 Swift 中，编写一个线程安全且标准的单例类是非常简洁的。我们需要遵循两个基本规则：
- 创建一个静态常量属性（
static let）作为单例实例。 - 使用私有的初始化器（
private init()）来阻止外部创建新实例。
#### 基础代码示例
让我们通过最基础的代码来看看它是如何工作的。下面的代码展示了一个名为 NetworkManager 的单例类，它模拟了网络请求的功能。
// 演示 Swift 中单例模式的基本结构
class NetworkManager {
// 1. 定义一个静态常量属性。
// Swift 的 ‘static let‘ 保证了该属性不仅全局唯一，
// 而且是线程安全的（Swift 底层保证了这一点，哪怕多线程同时访问，也只会初始化一次）。
// 我们通常将其命名为 ‘shared‘，这是 Swift 社区的命名惯例。
static let shared = NetworkManager()
// 2. 私有初始化器。
// 加上 ‘private‘ 关键字后，外部代码就无法使用 NetworkManager() 来创建新实例了。
// 这确保了 ‘shared‘ 是通往该类的唯一入口。
private init() {
print("NetworkManager 已初始化，这是唯一的实例")
}
// 一个示例功能函数
func fetchData() {
print("正在从服务器获取数据...")
}
}
// 使用单例
// 我们不需要创建新实例，直接通过类名访问静态属性
let manager = NetworkManager.shared
manager.fetchData()
在这个例子中，无论你在代码的多少个地方调用 NetworkManager.shared，你得到的永远都是内存中同一个对象的引用。
为什么要这样写？（深度解析）
你可能会问，为什么一定要用 INLINECODE90443e30 和 INLINECODE33a66727？让我们来拆解一下。
#### 1. 全局实例的命名规范
虽然你可以把那个静态属性命名为 INLINECODEe887f86e, INLINECODE69cbbdea 甚至 INLINECODE416b4b66，但在 Swift 开发社区（包括 Apple 官方库），最通用的命名是 INLINECODE752a2297。为什么？因为“单例”这个词强调的是“唯一的实例”，而“共享”强调的是“全局皆可访问”。使用 shared 会让你的 API 看起来更像原生代码，更具可读性。
#### 2. 线程安全的保障
在许多其他语言（如 Java 或 Objective-C 的早期写法）中，为了实现线程安全的单例，我们需要使用加锁机制或者特殊的“双重检查锁定”模式，甚至还要处理指令重排的问题。
但在 Swift 中，这一切都变得极其简单。Swift 的全局常量（INLINECODE114d45ce）在底层是由 dispatchonce 保证的。这意味着，INLINECODE2b03c0ee 这行代码在应用运行期间只会被执行一次，即使在多线程环境下，多个线程同时尝试访问 INLINECODEa95c03b8，系统也会确保只有一个线程负责初始化，其他线程会等待初始化完成。因此，在 Swift 中，上面的写法就是最标准、最线程安全的单例写法。
2026 视角：服务定位器与依赖注入
虽然 static let shared 很方便，但在 2026 年的现代 iOS 架构中，我们更倾向于结合“服务定位器”模式和“依赖注入”来使用单例。这样做不仅能保留单例的优点，还能极大地提升代码的可测试性和灵活性。
如果我们直接在 View Model 中硬编码 NetworkManager.shared，一旦我们需要在测试中替换网络层，就会变得非常麻烦。让我们来看看如何用更现代的方式重构这段代码。
#### 进阶代码示例：基于协议的服务定位
我们可以将单例作为依赖注入的默认提供者，而不是直接被调用。
// 定义一个协议，抽象出网络行为
protocol NetworkManaging {
func fetchData() -> String
}
// 实现具体的单例，但遵循协议
class ProductionNetworkManager: NetworkManaging {
// 依然使用标准的单例写法
static let shared = ProductionNetworkManager()
private init() {}
func fetchData() -> String {
return "真实网络数据"
}
}
// 容器/服务定位器（2026 常见模式）
class AppServices {
// 这里我们存储的是协议类型的单例
static let network: NetworkManaging = ProductionNetworkManager.shared
}
// 使用方：依赖抽象而非具体实现
class UserListViewModel {
private let networkService: NetworkManaging
// 构造注入：默认使用 AppServices 中的单例
init(networkService: NetworkManaging = AppServices.network) {
self.networkService = networkService
}
func loadUsers() {
let data = networkService.fetchData()
print("加载内容: \(data)")
}
}
// 在生产环境中
let viewModel = UserListViewModel()
viewModel.loadUsers() // 输出: 真实网络数据
// 在单元测试中
let mockService = MockNetworkManager() // 这是一个模拟对象
let testViewModel = UserListViewModel(networkService: mockService)
在这个例子中，我们虽然还是使用了单例，但通过 AppServices 容器和协议抽象，我们解耦了业务逻辑和具体实现。这符合 2026 年主流的“可测试架构”理念。
并发安全与数据竞争：Swift 6.0 的启示
随着 Swift 6.0 和 Swift Concurrency 的普及，我们在编写单例时必须更加关注“数据竞争”问题。传统的单例实例虽然是线程安全的，但单例内部的属性并不一定安全。
假设我们在多线程环境下修改单例中的配置，如果不加锁，就会崩溃。在 2026 年，我们更推荐使用 Swift 的 Actor 来构建单例。
#### 前沿代码示例：使用 Actor 构建线程安全单例
Actor 是 Swift 5.5 引入的类型，它自动保证内部状态的线程安全，无需开发者手动加锁。这是目前构建“状态型”单例的最佳实践。
// 使用 Actor 替代 Class 来实现自动线程安全的单例
// Actor 会通过“序列化”访问机制，确保同一时间只有一个线程可以修改其内部状态
actor AppConfiguration {
static let shared = AppConfiguration()
private init() {}
// Actor 内部的可变状态现在是安全的
private var apiKey: String = "default_key"
private var sessionToken: String?
// 更新 API Key
func updateApiKey(_ newKey: String) {
// 不需要 DispatchQueue.main.async 或 NSLock，Actor 自动处理
self.apiKey = newKey
print("API Key 已更新")
}
// 获取当前配置
func getCurrentConfig() -> (key: String, token: String?) {
return (self.apiKey, self.sessionToken)
}
}
// 使用示例
Task {
// Actor 的调用需要 await，因为可能涉及到跨线程调度
let config = await AppConfiguration.shared.getCurrentConfig()
print("当前 Key: \(config.key)")
await AppConfiguration.shared.updateApiKey("2026_secure_key")
}
为什么这很重要？
在传统的 INLINECODEd7358042 单例中，如果你忘记了加锁，Bug 往往很难复现（因为数据竞争是随机的）。而 INLINECODEefdf7a64 从编译器层面就杜绝了这种可能性。在我们最近的高并发服务端项目中，将单例重构为 Actor 彻底解决了偶发崩溃的问题。
实际应用场景示例
光说不练假把式。让我们通过几个更贴近实战的例子，看看单例是如何解决问题的。
#### 场景一：全局配置管理器
假设我们需要管理应用的主题颜色和用户设置。这些设置在应用的任何界面都需要用到。
// 演示如何使用单例管理全局应用设置
class AppSettings {
static let shared = AppSettings()
private init() {}
// 存储用户的偏好设置
var isDarkModeEnabled: Bool = false
var userName: String = "Guest"
// 提供一个方法来打印当前配置
func printCurrentSettings() {
print("用户: \(userName), 深色模式: \(isDarkModeEnabled)")
}
}
// 在应用的任何地方修改和读取配置
class ViewControllerA {
func updateTheme() {
// 我们不需要传递 settings 对象，直接访问
AppSettings.shared.isDarkModeEnabled = true
print("ViewController A: 切换到了深色模式")
}
}
class ViewControllerB {
func loadUserInfo() {
// 读取到的是最新的状态
if AppSettings.shared.isDarkModeEnabled {
print("ViewController B: 检测到深色模式，正在适配 UI...")
}
}
}
在这个例子中，INLINECODEcdca2255 修改了状态，INLINECODE1a5e6bf0 立刻就能读到。这就是单例在状态共享方面的威力。
#### 场景二：带参数访问的单例方法
有时候，单例不仅仅是存储数据，还需要执行特定的业务逻辑。我们可以给单例添加带有参数的方法。
// 演示带逻辑判断的单例方法
class AccessControlManager {
static let shared = AccessControlManager()
private init() {}
// 模拟一个内部数据库
private let allowedDomains = ["apple.com", "swift.org"]
// 检查访问权限的方法
func validateAccess(domain: String, completion: (Bool) -> Void) {
print("正在检查域名: \(domain)")
if allowedDomains.contains(domain) {
print("访问被允许")
completion(true)
} else {
print("访问被拒绝：未知域名")
completion(false)
}
}
}
// 使用示例
let accessManager = AccessControlManager.shared
accessManager.validateAccess(domain: "malicious-site.com") { success in
if success {
print("加载数据...")
} else {
print("警告：您没有权限访问此资源")
}
}
常见错误与最佳实践
在掌握了基本用法后，我们来聊聊开发者在写单例时常犯的错误，以及如何优化。
#### 错误 1：滥用单例导致“上帝对象”
问题： 初学者容易把所有的东西都塞进一个单例里。比如创建一个 Utils 单例，里面既有网络请求，又有数据库操作，还有日期格式化工具，甚至包含 UI 逻辑。这就是所谓的“上帝对象”，它会变得臃肿、难以维护。
解决方案： 保持单例的单一职责。如果网络逻辑和用户逻辑没有强耦合关系，建议拆分为 INLINECODEe81f64a9 和 INLINECODE6373f745。
#### 错误 2：在单例中持有强引用导致循环引用
问题： 单例是长期存在于内存中的。如果你在单例中持有了 INLINECODE63672f6c 或 INLINECODE96537079 的强引用（例如 var currentViewController: UIViewController?），那么这些界面控制器将永远无法被释放，从而导致严重的内存泄漏。
解决方案：
- 尽量不要在单例中直接持有 UI 对象。
- 如果必须持有，请务必使用
weak引用：
// 正确使用弱引用避免内存泄漏
class NavigationService {
static let shared = NavigationService()
private init() {}
// 使用 weak 修饰，这样当界面被销毁时，单例不会阻止它释放
weak var currentViewController: UIViewController?
func registerView(_ controller: UIViewController) {
self.currentViewController = controller
print("视图已注册: \(controller)")
}
}
总结
在这篇文章中，我们全面地探讨了 Swift 中的单例模式。我们不仅学习了如何编写线程安全的基础单例代码，还深入研究了 static let 背后的线程安全机制，以及如何通过单例管理全局配置。
关键要点如下：
- 标准写法： 始终使用 INLINECODE7d6ffd83 和 INLINECODEb461843a。
- 命名规范： 使用
shared作为属性名，保持代码风格的一致性。 - 警惕陷阱： 避免在单例中存储 UI 对象的强引用，防止内存泄漏。
- 保持克制： 不要创建功能过于庞大的“上帝单例”，尽量保持单一职责。
- 可测试性： 在复杂的业务逻辑中，考虑通过协议和依赖注入来使用单例，以提升代码的可测试性。
- 2026 趋势： 优先考虑使用
Actor来构建包含可变状态的单例，以确保现代并发模型下的安全。
单例是一把双刃剑，用好了能让代码结构清晰、全局状态管理井井有条；用不好则会变成一团乱麻。希望这篇文章能让你对单例模式有更深刻的理解，在未来的项目中能够写出更专业、更优雅的 Swift 代码。