在 Swift 开发中，结构体（struct）的属性声明常面临 let 与 var 的抉择。本文将从多个维度解析两者的差异，并结合实际场景提供决策建议。
一、基础差异：不可变性与初始化行为
1. 不可变性的连锁反应
struct User {
let id: UUID
let imageURL: URL?
}
// 必须显式传递 nil
let user = User(id: UUID(), imageURL: nil)
- 强制显式性：
let属性要求初始化时必须赋值（包括nil） - 解码限制：若遵循
Decodable，let属性会忽略 JSON 中的同名字段
2. 默认值的陷阱
struct User {
let id = UUID() // 编译错误！无法覆盖默认值
}
- 编译期锁定：
let的默认值无法被外部赋值覆盖 - 初始化器必要性：需手动实现初始化器才能保留默认值灵活性
二、进阶方案：平衡不可变性与便利性
1. 手动初始化器的优雅退场
struct User {
let id: UUID
let imageURL: URL?
init(id: UUID = UUID(), imageURL: URL? = nil) {
self.id = id
self.imageURL = imageURL
}
}
- 双重优势：保持属性不可变的同时支持默认值
- 维护成本：需手动编写和维护初始化逻辑
2. 属性包装器的魔法
@propertyWrapper struct Readonly<Value: Codable> {
let wrappedValue: Value
}
struct User {
@Readonly var id = UUID()
@Readonly var imageURL: URL?
}
- 复用性：通过包装器实现
var声明的只读特性 - 协议兼容：需额外实现
Encodable/Decodable协议扩展
三、争议焦点：可变性的取舍
1. 极简主义路线
struct User {
var id = UUID()
var name: String
// 其他属性均为 var
}
- 测试友好：便于模拟状态变化（如
normalizeName()测试） - 潜在风险：暴露不必要的可变性（需依赖调用者自律）
2. 结构体的本质思考
protocol UserTransformer {
mutating func transform(_ user: inout User)
}
// 可能的滥用场景
struct UserIDTransformer: UserTransformer {
func transform(_ user: inout User) {
user = User(id: UUID(), name: user.name) // 完全替换实例
}
}
- 值类型的陷阱：
inout参数允许完全替换底层实例 - 防御性编程：重要属性应通过业务逻辑层保护
四、决策框架与最佳实践
1. 属性分类指南
| 属性类型 | 推荐修饰符 | 典型场景 |
|---|---|---|
| 核心标识符 | let | id, primaryKey |
| 可选配置项 | let? | imageURL |
| 计算衍生属性 | var | fullName |
| 需要默认值 | let+初始化器 | createdAt = Date() |
2. 实战建议
- **优先使用
let**：除非明确需要可变性 - 初始化器先行：通过自定义初始化保持 API 清晰
- 防御性包装：关键属性可通过访问控制限制修改权限
- **审慎使用
inout**：在需要改变实例时优先返回新实例
五、未来趋势展望
随着 Swift 演进，以下方向值得关注：
- 不可变集合：Swift 5.7+ 引入的
@resultBuilder可能催生新型不可变模式 - 值类型增强：SE-0353 提案探索更高效的值类型复制机制
- 协程集成：Async/Await 与结构体的结合可能改变状态管理范式
结语：let 与 var 的选择本质上是数据模型设计的哲学问题。建议采用「最小权限原则」——仅在必要时引入可变性，并通过清晰的接口契约约束变更行为。记住，Swift 的强大之处在于其表达能力，合理利用语言特性能让代码既安全又优雅。
