Swift处理REST部分JSON响应：是否需将所有属性设为可选？

绝对不建议把所有属性都改成可选类型——这会直接丢失编译时的类型安全优势，业务代码里要到处处理不必要的可选绑定，还会模糊数据库中“必填字段”的语义。针对你的场景，有几个更优雅的处理模式：

1. 拆分API层与业务层结构体 #

这是最清晰的方案：专门创建一个用于处理API部分响应的结构体，所有属性设为可选；业务层则保留符合数据库约束的结构体（仅phoneNumber可选）。两者通过转换逻辑衔接，既灵活处理API的部分响应，又保证业务代码的类型安全。

示例代码：

// API层：专门适配部分响应
public struct APIPartialUser: Decodable {
    var id: Int?
    var firstName: String?
    var lastName: String?
    var phoneNumber: String?
    var verified: Bool?
}

// 业务层：严格遵循数据库约束
public struct User {
    var id: Int
    var firstName: String
    var lastName: String
    var phoneNumber: String?
    var verified: Bool
    
    // 从API部分响应转换，处理缺失必填字段的情况
    init(from partial: APIPartialUser) throws {
        guard let id = partial.id,
              let firstName = partial.firstName,
              let lastName = partial.lastName,
              let verified = partial.verified else {
            throw APIError.missingRequiredFields("部分响应缺失必填字段")
        }
        self.id = id
        self.firstName = firstName
        self.lastName = lastName
        self.phoneNumber = partial.phoneNumber
        self.verified = verified
    }
}

// 自定义错误类型，方便调试
enum APIError: Error {
    case missingRequiredFields(String)
}

使用时，先解码APIPartialUser，再根据业务需求转换为User——如果API返回的部分响应包含所有必填字段，转换成功；否则抛出错误，你可以根据情况重试请求、提示用户，或者做其他降级处理。

2. 自定义解码逻辑，保留必填语义 #

如果不想拆分结构体，可以通过自定义init(from decoder:)方法，在解码时强制检查必填字段，缺失时抛出明确的错误，而不是依赖系统默认的解码失败。

示例代码：

public struct User: Decodable {
    var id: Int
    var firstName: String
    var lastName: String
    var phoneNumber: String?
    var verified: Bool
    
    enum CodingKeys: String, CodingKey {
        case id, firstName, lastName, phoneNumber, verified
    }
    
    public init(from decoder: Decoder) throws {
        let container = try decoder.container(keyedBy: CodingKeys.self)
        
        // 对必填字段做强制检查，缺失时抛出带明确信息的错误
        self.id = try container.decodeIfPresent(Int.self, forKey: .id) ?? {
            throw DecodingError.dataCorruptedError(
                forKey: .id,
                in: container,
                debugDescription: "ID是必填字段，但部分响应中缺失"
            )
        }()
        
        self.firstName = try container.decodeIfPresent(String.self, forKey: .firstName) ?? {
            throw DecodingError.dataCorruptedError(
                forKey: .firstName,
                in: container,
                debugDescription: "名字是必填字段，但部分响应中缺失"
            )
        }()
        
        self.lastName = try container.decodeIfPresent(String.self, forKey: .lastName) ?? {
            throw DecodingError.dataCorruptedError(
                forKey: .lastName,
                in: container,
                debugDescription: "姓氏是必填字段，但部分响应中缺失"
            )
        }()
        
        self.phoneNumber = try container.decodeIfPresent(String.self, forKey: .phoneNumber)
        
        self.verified = try container.decodeIfPresent(Bool.self, forKey: .verified) ?? {
            throw DecodingError.dataCorruptedError(
                forKey: .verified,
                in: container,
                debugDescription: "验证状态是必填字段，但部分响应中缺失"
            )
        }()
    }
}

这种方式的好处是保持结构体的语义清晰，但缺点是如果API经常返回不同组合的部分响应，解码逻辑会变得繁琐。

总结 #

优先选择拆分API与业务层结构体的方案，它既能灵活适配API的部分响应特性，又能在业务代码中严格保证必填字段的类型安全，避免不必要的可选处理。

内容的提问来源于stack exchange，提问作者Prabhu