Factory 项目中 @Injected 属性包装器的 Sendable 兼容性问题解析

问题背景

在 Swift 并发编程中，Sendable 协议扮演着重要角色，它用于标记可以在不同并发域之间安全传递的类型。随着 Xcode 16 和 Swift 6 的推出，对并发安全的检查变得更加严格。Factory 作为一个流行的依赖注入框架，在 2.4.0 版本中已经为并发使用做了优化，但在特定场景下仍存在 Sendable 兼容性问题。

问题现象

当开发者尝试在符合 Sendable 协议的结构体中使用 @Injected 属性包装器注入同样符合 Sendable 协议的依赖时，Xcode 会报错：

Stored property '_sendableClass' of 'Sendable'-conforming struct 'SendableStruct' has non-sendable type 'Injected<SendableClass>'

问题本质分析

这个问题表面上是 Factory 框架的问题，实际上涉及 Swift 语言对属性包装器和 Sendable 检查的交互机制：

1. 属性包装器的本质：在 Swift 中，属性包装器实际上会生成一个存储属性（通常以 _ 为前缀）和一个计算属性。即使原始属性声明为 let，生成的存储属性仍然是 var，这影响了 Sendable 检查。

2. Sendable 的严格要求：Sendable 协议要求所有存储属性都必须是 Sendable 的。对于可变属性（var），Swift 会特别严格检查，因为可变状态在多线程环境下容易引发数据竞争。

3. 框架设计考量：Factory 的 @Injected 属性包装器主要用于依赖注入场景，虽然实际使用中开发者不会修改这些注入的属性，但 Swift 编译器无法识别这种使用模式，只能基于语言规则进行检查。

解决方案

Factory 的维护者最终通过为 Injected 类型添加条件性 Sendable 一致性解决了这个问题：

extension Injected: @unchecked Sendable where T: Sendable {}

这里使用了 @unchecked 标记，因为：

1. 安全考虑：虽然 T 是 Sendable 的，但 Injected 内部可能包含一些同步机制或状态，需要开发者确保线程安全。

2. 灵活性：@unchecked 允许框架在保持 Sendable 兼容性的同时，将线程安全的保证责任交给具体实现。

最佳实践建议

1. 明确依赖的生命周期：对于需要在并发环境中使用的依赖，确保它们确实是线程安全的。

2. 谨慎使用 @unchecked Sendable：虽然框架提供了这个解决方案，但在自己的代码中应尽量实现真正的线程安全。

3. 考虑替代方案：如果对并发安全有极高要求，可以考虑在初始化时直接通过 Container 获取依赖，而不是使用属性包装器。

4. 关注 Swift 演进：未来如果 Swift 支持属性包装器用于 let 属性，这个问题可能会有更优雅的解决方案。

总结

这个问题展示了 Swift 并发模型与实际框架设计之间的微妙交互。Factory 通过条件性 @unchecked Sendable 一致性提供了一个实用的解决方案，平衡了便利性和安全性。作为开发者，理解这些底层机制有助于更好地使用并发特性和依赖注入框架。