SwiftData崩溃问题：使用含可选属性的非可选结构体作为@Model属性时触发“Passed nil for a non-optional keypath”错误

我完全理解你遇到的这个棘手问题——SwiftData在处理非可选结构体内部包含可选属性的场景时，确实存在这个容易误导人的崩溃问题。报错信息看起来像是myStruct本身为nil，但实际上你已经正确初始化了它，问题根源在于SwiftData对Codable结构体的默认持久化逻辑存在兼容性缺陷。

问题原因分析 #

当你依赖SwiftData默认的Codable支持来持久化MyStruct时，它会尝试解析结构体的内部属性。如果结构体里有初始为nil的可选属性，SwiftData会错误地将整个结构体的keypath标记为nil，触发非可选属性的断言检查（也就是你看到的Fatal error: Passed nil for a non-optional keypath \MyModel.myStruct）。这个问题和SwiftData对Codable类型的嵌套可选值处理逻辑有关，而非你的代码逻辑错误。

最优解决方案（无需修改MyStruct） #

我们可以通过让MyStruct实现PersistentRepresentable协议，手动控制结构体的持久化逻辑，绕过SwiftData的默认Codable处理缺陷。这个方案完全不需要修改MyStruct的内部结构，只需要添加一个扩展：

extension MyStruct: PersistentRepresentable {
    // 定义持久化时使用的底层类型（这里用Data，通过JSON编解码实现）
    public typealias PersistedType = Data
    
    // 从持久化的Data还原结构体
    public init?(persistedValue: Data) {
        guard let decoded = try? JSONDecoder().decode(MyStruct.self, from: persistedValue) else {
            return nil
        }
        self = decoded
    }
    
    // 将结构体编码为可持久化的Data
    public var persistedValue: Data {
        guard let encoded = try? JSONEncoder().encode(self) else {
            return Data()
        }
        return encoded
    }
}

方案原理 #

PersistentRepresentable协议是SwiftData提供的自定义持久化逻辑入口，它告诉SwiftData：

1. 如何将你的结构体转换为数据库可以存储的类型（这里用Data）
2. 如何从存储的类型还原回你的结构体

通过这种方式，SwiftData不再依赖默认的Codable解析逻辑，也就不会触发原来的nil断言错误，同时完全保留MyStruct的原有结构和功能。

验证效果 #

将上述扩展添加到你的代码中后，点击"Add"按钮创建新模型时，崩溃将不再发生。你可以正常使用MyStruct内部的可选属性，同时保持MyModel中myStruct的非可选属性定义。

备选妥协方案（不推荐，仅作参考） #

如果你暂时不想实现PersistentRepresentable，可以在MyModel的初始化方法中，给MyStruct的value属性一个非nil的默认值（比如空字符串），但这需要修改初始化代码，且不符合你“不修改MyStruct”的偏好：

// 仅作备选，不推荐
init(name: String) {
    self.name = name
    // 用空字符串替代nil
    self.myStruct = MyStruct(value: "")
}

总结 #

这个问题属于SwiftData对嵌套可选属性的Codable结构体的兼容性问题，通过实现PersistentRepresentable协议是最符合你需求的解决方案——既不需要修改MyStruct的内部结构，又能彻底解决崩溃问题。

内容来源于stack exchange