前后端JSON结构选型与数据处理职责划分技术咨询

不存在绝对“更优”的单方案，行业通用的最佳实践是采用后端视角的语义化通用结构作为接口标准输出，前端单独抽离数据适配层完成UI格式转换，不要让后端直接耦合前端UI展示逻辑，也不要让前端各组件零散重复做数据转换。

两种方案的优劣势对比 #

后端视角的结构化方案（第一种） #

这是更合理的服务层输出设计，核心优势：

• 语义清晰无歧义：每个字段对应明确的业务含义，没有展示层的语义污染，后续做数据校验、逻辑扩展（比如邻居信息脱敏、证据置信度统计、多系统数据打通）都不需要反向解析字段。
• 复用性强：同一套接口可以同时服务Web端、App、小程序、管理后台、第三方开放平台等所有调用方，不需要为不同端单独定制返回结构。
• 迭代成本低：业务逻辑的调整只需要修改对应业务字段即可，不需要跟着UI改版频繁动接口结构。

注：该方案目前存在字段命名不规范（比如neighbor name带空格、大小写风格不统一）的问题，属于实现细节，统一成驼峰/下划线命名规范即可，不影响架构选型。

它的唯一问题是没有和前端UI结构做映射，直接使用会增加前端的重复判断逻辑。

前端视角的UI适配方案（第二种） #

仅适合极小的、无扩展需求的Demo类项目，生产环境用会有明显硬伤：

• 维护成本极高：UI是产品迭代最频繁的部分，今天要label/sublabel的结构，明天可能要加头像字段、把手机号挪到二级弹窗、调整展示文案，后端需要跟着UI改版频繁改接口，完全打破前后端分离的职责边界。
• 复用性极差：不同端的UI展示逻辑完全不同，你不可能给管理后台、移动端、第三方调用方都返回同一套label/content结构，后续接新端就得加新接口或者做大量兼容判断。
• 业务语义丢失：把邻居姓名、手机号这类强业务属性的字段硬套成通用展示字段，后续要做业务逻辑处理（比如给邻居发寻猫通知、校验手机号格式）时，需要反向从展示字段里抠业务数据，很容易出bug。

落地建议 #

1. 后端层坚持输出通用业务结构：不要在接口返回里掺杂任何UI相关的字段命名（比如label/content/sublabel这类纯展示属性），保证接口的业务中立性。
2. 前端统一抽离数据适配层（Adapter/Transformer）：在接口请求返回后、业务组件渲染前，统一在适配层完成后端数据到UI结构的转换，不要让每个组件零散写数据处理逻辑，避免逻辑不一致。参考转换示例：

// 前端统一数据转换层
function transformTrackNode(apiRawData) {
  const baseNode = {
    id: apiRawData.nodeId,
    linkedTo: apiRawData.linkedTo,
    evidenceConfidence: apiRawData.evidenceConfidence,
    explanation: apiRawData.explanation,
    recordType: apiRawData.recordType
  }

  // 按不同业务类型映射成UI需要的展示结构
  switch(apiRawData.recordType) {
    case 'evidence':
      return {
        ...baseNode,
        content: '邻居反馈该猫咪常居此地址',
        label: apiRawData.recordDetail.neighborName,
        sublabel: apiRawData.recordDetail.neighborPhone,
        additionalInfo: `证据类型：${apiRawData.recordDetail.evidenceType}`
      }
    case 'catOwnershipDetermination':
      // 其他类型节点的转换逻辑统一维护在这里
      return {
        ...baseNode,
        // 对应UI字段映射
      }
    default:
      return baseNode
  }
}

3. 例外情况：如果是个人开发的极小Demo、确定后续不会做多端适配、UI也不会有大的调整，完全可以怎么快怎么来，直接用前端视角的结构省掉转换逻辑，不需要硬套架构规范。

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