API响应空值处理：可空模型vs非可空模型的最佳实践

场景说明 #

你需要处理含空值的API响应，示例返回数据如下：

"data": {
    "email": null,
    "username": "Janet"
}

要将该数据存入UserModel，目前有两种实现方案，以下是具体分析和最佳实践建议：

方案一：使用非可空模型 #

定义字段均为非可空类型的模型，通过空值合并运算符处理API返回的null：

class UserModel {
  final String email;
  final String username;

  UserModel({required this.email, required this.username});
}

实例化时处理空值：

UserModel(
  email: data['email'] ?? '', 
  username: data['username'] ?? '',
),

方案二：定义可空字段的模型 #

直接将字段声明为可空类型，允许传入null：

class UserModel {
  String? email;
  String? username;

  UserModel({this.email, this.username});
}

最佳实践分析 #

选择哪种方案核心取决于业务语义和代码维护需求，具体分情况讨论：

1. 基于业务语义判断 #

• 如果email是用户必须具备的属性（只是API暂时未返回，比如用户未完善资料），优先选方案一：用空字符串作为默认值，保证模型字段始终有值，符合“必填属性”的业务定义。
• 如果email本身是可选属性（比如部分用户无需绑定邮箱），选方案二：通过String?明确标注字段的可选性，精准匹配业务逻辑，避免用默认值模糊“未设置”的语义。

2. 基于代码安全性与简洁性判断 #

• 方案一优势：后续使用user.email时无需额外判空，减少空指针风险，代码更简洁。但要确保默认值（如空字符串）符合业务对“未设置”的定义，避免语义混淆。
• 方案二优势：能精准区分“API返回null（未获取到值）”和“主动设置为空”的差异，但后续使用该字段时必须处处判空（如user.email?.isEmpty），增加代码复杂度。

3. 基于扩展性判断 #

• 若后续API返回的空值语义可能变化（比如null代表“未获取”，空字符串代表“用户主动清空”），方案二更能适配这种差异。
• 若业务上始终将“未返回邮箱”等同于“空邮箱”，方案一的默认值处理更省心，减少后续代码调整成本。

总结建议 #

• 优先以业务语义为核心判断标准：确定字段是必填还是可选。
• 必填字段但API可能返回null：用方案一，搭配合理的默认值（如空字符串、占位符）。
• 可选字段：用方案二，明确标注可空性，避免滥用默认值导致语义模糊。

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