GraphQL Schema设计中Interface与Union建模方案的选型权衡

核心本质差异 #

两种方案的设计思路完全不同，不存在绝对的好坏，核心区别可以归纳为两点：

• Interface方案走类型继承逻辑：把所有事件的公共属性抽成顶层Event契约，地震、飓风等具体灾害类型直接实现这个接口，属于「is-a（是一种事件）」的关系，Interface本身会定义所有实现类型必须遵守的公共字段契约，Union本身不承载任何字段定义。
• Union方案走组合嵌套逻辑：顶层Event是时间线场景专属的包装壳，只存分页、事件标识这类通用元数据，不同灾害的独有业务属性完全收敛在独立的payload类型中，通过Union关联到Event上，属于「has-a（包含一个具体灾害实体）」的关系。

方案1：Interface接口方案优劣势 #

优势 #

• 查询写法简洁，尤其是适配游标分页场景时，公共的id、occurred字段和分页边、游标信息同层，不需要额外嵌套就能直接获取，前端写查询、解析数据的路径更短。典型查询写法如下：

query GetEventTimeline($cursor: String) {
  events(first: 20, after: $cursor) {
    edges {
      node {
        id
        occurred
        ... on Earthquake {
          magnitude
          epicenter
        }
        ... on Hurricane {
          force
        }
      }
      cursor
    }
    pageInfo {
      hasNextPage
    }
  }
}

• 领域语义直观：地震、飓风本身就是自然灾害事件的细分类型，符合大部分人对业务模型的直觉，新开发上手理解成本低。
• 公共字段扩展有强制契约约束：后续如果要给所有事件加通用字段（比如事件上报来源、影响等级），直接在Event接口上新增即可，所有实现类型会被GraphQL校验强制要求实现该字段，不会出现漏加的情况。

劣势 #

• 类型耦合度高：具体的地震、飓风类型和Event接口强绑定，如果后续需要在地质模块单独查询地震列表、在气象模块单独查询飓风列表，复用这些类型时会被强制带上时间线场景的id、occurred字段约束，灵活性差。
• 容易出现契约污染：迭代过程中如果遇到部分事件共有的「半公共字段」，很容易被随手加到顶层接口里，导致不需要该字段的实现类型被迫返回无意义空值，破坏接口的严谨性。
• 字段冲突处理成本高：不同子类型如果出现同名字段但语义不一致的情况（比如地震的magnitude是里氏震级，飓风后续要加的magnitude是风力等级），要么妥协字段语义，要么修改字段名增加额外的认知成本。

方案2：Union联合类型方案优劣势 #

优势 #

• 职责边界极其清晰：顶层Event只负责时间线场景的通用逻辑（分页、全局事件ID、发生时间），具体灾害的业务属性完全独立，和时间线元数据完全解耦。
• 类型复用性强：Earthquake、Hurricane这类只存业务属性的类型，没有绑定任何场景专属字段，可以直接在地质、气象等其他业务模块的查询中复用，不需要重复定义相同结构的类型。
• 无字段冲突风险：不同payload类型的字段完全独立，就算出现同名属性也不会互相干扰，不需要为了迁就接口契约妥协字段命名或语义。

劣势 #

• 查询多一层嵌套：所有具体灾害的属性都要通过payload字段获取，写查询时需要多嵌套一层类型片段，前端解析数据时也要多走一层路径，典型查询写法如下：

query GetEventTimeline($cursor: String) {
  events(first: 20, after: $cursor) {
    edges {
      node {
        id
        occurred
        payload {
          ... on Earthquake {
            magnitude
            epicenter
          }
          ... on Hurricane {
            force
          }
        }
      }
      cursor
    }
    pageInfo {
      hasNextPage
    }
  }
}

• 领域语义和直觉有偏差：和「飓风是一种事件」的常规认知不同，该方案的逻辑是「时间线条目包含一个飓风实体」，新接触项目的开发需要先理解这层包装逻辑，初期上手成本稍高。
• 公共属性扩展没有强制约束：如果后续需要给所有灾害类型加一个公共业务属性，必须在每个payload类型里单独添加，没有统一的契约做校验，容易出现部分类型漏加、字段类型不一致的问题。

选型权衡判断标准 #

不需要纠结哪种方案更「先进」，结合自己的业务场景按三个维度判断即可：

• 看子类型的复用需求：如果地震、飓风这类类型只会在事件时间线场景使用，不会被其他模块单独查询，优先选Interface方案，语义和写法都更简洁；如果这些类型本身是其他业务模块的核心实体，需要跨场景复用，优先选Union方案，避免类型耦合。
• 看公共字段的归属：如果id、occurred这类字段本身就是灾害实体的固有属性（比如地震的发生时间就是地震本身的属性，不是时间线额外加的），选Interface更合理；如果这些字段是时间线场景给事件打的元数据（比如同一个地震实体可能被不同时间线引用，有不同的事件ID），选Union更符合逻辑。
• 看后续事件类型的差异度：如果后续要加的山洪、森林火灾等其他灾害类型，和现有类型的业务属性重合度极低，没有统一的业务公共字段，选Union方案更灵活，不会被顶层接口的契约绑死；如果所有灾害类型的业务属性结构高度相似，只是个别字段有差异，选Interface维护成本更低。

针对当前做自然灾害时间线+游标分页的场景，如果整个服务的核心就是统一管理各类自然灾害事件，没有跨模块复用灾害类型的需求，直接选Interface即可；如果灾害数据分别来自地质、气象等独立的业务服务，只是需要聚合到时间线做统一分页查询，选Union方案解耦性更好。

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