移动端应用模型类管理最佳实践：User类属性扩展方案咨询

针对你遇到的User模型扩展问题，下面分析几种常见方案的优劣，并给出实践建议：

方案1：全字段设为Nullable（当前做法） #

• 优势：无需大幅修改现有代码，模型保持统一，不同模块不用切换类。
• 劣势：字段语义模糊，无法区分「字段不存在」和「字段存在但为空」；上层调用需频繁判空，容易引发空指针问题；随着业务扩展，模型会越来越臃肿，维护成本升高。

方案2：继承扩展（如UserDetail extends User） #

• 优势：保留基础User的简洁性，扩展类承载额外字段，符合单一职责原则。
• 劣势：若后续有多种扩展场景（如用户统计、设置信息），会导致继承链复杂；跨模块传递时需类型转换，增加代码复杂度；部分序列化框架对继承的支持存在兼容性问题。

方案3：新建独立模型类（如UserListItem、UserDetail） #

• 优势：每个模型职责明确，字段可设为非空（只要API返回确定存在），上层调用无需频繁判空；不同模块的模型独立维护，避免耦合。
• 劣势：类数量会增加；公共字段可能重复（可通过定义公共接口/组合类解决，比如UserCore接口包含id、name，让UserListItem和UserDetail实现该接口）。

推荐实践 #

场景1：不同模块对应不同API接口（列表接口返回基础字段，详情接口返回全量字段） #

优先选择新建独立模型+公共接口/组合的方式：

1. 定义UserCore接口，包含所有模块共享的字段（id、name）；
2. 列表模块使用UserListItem，实现UserCore并添加age字段；
3. 详情模块使用UserDetail，实现UserCore并添加address、email等字段。
   这种方式既保证公共字段复用，又让每个模型职责清晰，避免空值处理的麻烦。

场景2：同一API后续新增字段，或不同模块复用同一份数据 #

可以继续使用Nullable字段，但需优化：

• 在模型字段上添加详细注释，明确标注哪些字段在哪些场景下会被填充；
• 封装安全访问方法（比如getAddressOrEmpty()），避免上层代码直接处理Nullable字段，降低空指针风险。

额外建议 #

• 不要为了减少类数量强行统一模型，清晰的职责比类的数量更重要；
• 若使用跨平台框架（如Flutter、React Native），可利用语言特性简化重复代码（比如Dart的mixin、TypeScript的接口继承）。

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