Swift 结构体属性：let 与 var 的选择艺术

在 Swift 开发中，结构体（struct）的属性声明常面临 let 与 var 的抉择。本文将从多个维度解析两者的差异，并结合实际场景提供决策建议。

一、基础差异：不可变性与初始化行为

1. 不可变性的连锁反应

swift 复制代码

struct User {
    let id: UUID
    let imageURL: URL?
}

// 必须显式传递 nil
let user = User(id: UUID(), imageURL: nil)

强制显式性 ：let 属性要求初始化时必须赋值（包括 nil）
解码限制 ：若遵循 Decodable，let 属性会忽略 JSON 中的同名字段

2. 默认值的陷阱

swift 复制代码

struct User {
    let id = UUID() // 编译错误！无法覆盖默认值
}

编译期锁定 ：let 的默认值无法被外部赋值覆盖
初始化器必要性：需手动实现初始化器才能保留默认值灵活性

二、进阶方案：平衡不可变性与便利性

1. 手动初始化器的优雅退场

swift 复制代码

struct User {
    let id: UUID
    let imageURL: URL?
    
    init(id: UUID = UUID(), imageURL: URL? = nil) {
        self.id = id
        self.imageURL = imageURL
    }
}

双重优势：保持属性不可变的同时支持默认值
维护成本：需手动编写和维护初始化逻辑

2. 属性包装器的魔法

swift 复制代码

@propertyWrapper struct Readonly<Value: Codable> {
    let wrappedValue: Value
}

struct User {
    @Readonly var id = UUID()
    @Readonly var imageURL: URL?
}

复用性 ：通过包装器实现 var 声明的只读特性
协议兼容 ：需额外实现 Encodable/Decodable 协议扩展

三、争议焦点：可变性的取舍

1. 极简主义路线

swift 复制代码

struct User {
    var id = UUID()
    var name: String
    // 其他属性均为 var
}

测试友好 ：便于模拟状态变化（如 normalizeName() 测试）
潜在风险：暴露不必要的可变性（需依赖调用者自律）

2. 结构体的本质思考

swift 复制代码

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 的强大之处在于其表达能力，合理利用语言特性能让代码既安全又优雅。