托管项目中实体status字段应如何设计以方便前端团队使用

方案1：给枚举附加展示分类属性（最推荐） #

直接在你现有HostingStatus枚举的定义中新增前端展示需要的分类属性，后端返回数据时同步返回该属性，前端不需要做任何映射逻辑：

// 改造后的枚举类
enum class HostingStatus(val displayCategory: String) {
    CREATION_PENDING("ACTIVE"),
    CREATION_SUCCESS("ACTIVE"),
    CREATION_FAILED("FAIL"),
    RENEW_PENDING("ACTIVE"),
    RENEW_SUCCESS("ACTIVE"),
    RENEW_FAILED("ACTIVE"), // 按需求归为active类
    SUSPEND_PENDING("SUSPEND"),
    SUSPEND_SUCCESS("SUSPEND"),
    SUSPEND_FAILED("ACTIVE"),
    UPGRADE_PENDING("ACTIVE"),
    UPGRADE_SUCCESS("ACTIVE"),
    UPGRADE_FAILED("ACTIVE"), // 按需求归为active类
    ...
}

接口返回托管实例数据时，把displayCategory同步返回给前端，前端直接用这个属性值匹配对应的三类图标即可。

方案2：DTO层新增专属展示字段（适合不想改动原始枚举的场景） #

如果不想侵入原始业务枚举的定义，可以在返回给前端的DTO层单独新增展示用的状态字段，后端自己维护映射逻辑：

// 给前端返回的DTO结构
data class HostingInstanceDTO(
    val hostingId: String,
    val customerId: String,
    // 保留原始业务状态，供特殊业务逻辑判断使用
    val status: HostingStatus,
    // 专门给前端展示用的状态分类，值固定为ACTIVE/SUSPEND/FAIL三类
    val displayStatus: String,
    ...
)

后端在组装DTO时，内部完成HostingStatus到displayStatus的映射，后续新增业务状态只要更新后端的转换逻辑，前端完全无感知。

额外优化建议 #

你现有结构里的active布尔字段可以考虑废弃，避免出现状态不一致的问题（比如状态是SUSPEND_SUCCESS但active字段为true的异常情况），所有状态判断都可以通过HostingStatus及其附加属性完成，减少冗余字段带来的潜在bug。

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