参考原文：Understanding opaque types and protocols with associatedtype in Swift
环境：Swift 6.2 + Xcode 26
why：带 associatedtype 的协议为何不能当返回值？
protocol Store {
associatedtype Item
func persist(item: Item)
}
// ❌ 编译失败：Protocol 'Store' can only be used as a generic constraint
func makeStore() -> Store { ... }
- associatedtype 未被确定 → 编译期无法决定具体内存布局。
- Swift 拒绝“协议当作类型”使用，除非用泛型或 opaque 类型。
传统 workaround：泛型约束
func makeStore<T: Store>() -> T { ... } // ✅ 可行，但调用端要写类型
痛点：
- 调用处仍需显式指定类型
- 代码膨胀（每种 T 一份实现）
- 无法隐藏实现细节（返回类型泄露）
Swift 5.1+ 解法：opaque 类型 (some)
func makeStore() -> some Store {
return UserDefaultsStore() // 具体类型被隐藏，调用端只认 Store 协议
}
- 返回类型由编译器推断，调用者无需知道
UserDefaultsStore。 - 内存布局确定（编译期知道真实类型大小）。
- 语法糖：等价于“泛型参数由编译器自动填充”。
opaque vs 泛型 vs 存在容器（any）速查表
| 特性 | 具体类型 | 内存布局 | 性能 | 隐藏实现 | 调用端写法 | 适用场景 |
|---|---|---|---|---|---|---|
opaque (some) | 编译期已知 | 静态派发，无额外开销 | 最优 | ✅ | 最简洁 | 返回值/参数想隐藏具体类型 |
泛型 <T: Store> | 调用者指定 | 静态 | 最优 | ❌ | 需显式类型 | 需要多类型复用实现 |
存在容器 (any Store) | 运行时动态 | 存在容器（1 ptr + metadata） | 动态派发，略慢 | ✅ | 同 opaque | 需要运行时异构集合 |
实战：同一函数三种写法对比
// 1. 泛型 — 调用者决定类型
func makeStore<T: Store>() -> T { T() }
// 2. Opaque — 实现者决定类型，调用者无感
func makeStore() -> some Store { UserDefaultsStore() }
// 3. 存在容器 — 运行时多态
func makeStore() -> any Store { UserDefaultsStore() }
调用侧：
let s1: some Store = makeStore() // 编译期知道真实类型
let s2: any Store = makeStore() // 运行时才知道
什么时候选 opaque？
- 只想隐藏返回类型，不关心具体实现
- 性能敏感（避免存在容器额外间接层）
- API 向前兼容——日后可无缝换成别的具体类型，不破坏二进制接口
一句话总结
带 associatedtype 的协议不能当返回值？
用 some Protocol 就行！
它 = “编译期泛型” + “实现细节隐藏” + “零成本抽象”，
让协议真正像“类型”一样使用，而无需把泛型复杂性抛给调用者。
