接口响应数据：列表类型VS含布尔值的对象，哪种方案更优？

两种方案各有优劣，没有绝对的“更合适”，得结合业务场景、带宽限制、扩展性需求来选，具体分析如下：

方案A：用布尔键值对标识所有状态 #

这种方案把每个可能的状态都明确写成键值对，true表示激活，false表示未激活。

优点 #

• 语义绝对清晰：前端/客户端拿到数据不需要猜测，直接读取clicked、visited的布尔值即可，不会出现“这个状态没写到底是false还是漏了”的歧义
• 扩展性强：后续新增状态时，直接在对象里加新键值对就行，不会影响现有逻辑
• 调试追踪方便：状态从true变false或者反过来，日志里能直接看到字段值变化，排查问题更高效

缺点 #

• 响应体积偏大：如果大部分状态都是false，会携带一堆冗余字段，浪费带宽
• 状态过多时结构臃肿：如果有几十上百个状态，对象会变得冗长，解析时的内存占用也会更高

示例代码：

{
  "param1": {
    "clicked": false,
    "visited": true
  },
  "desktop_app": {
    "installed": true,
    "removed": false
  },
  "chekpoints": {
    "2021-W43": {
      "choice_done": true,
      "slide_in_seen": true
    },
    "2021-W44": {
      "meal_choice_done": false,
      "slide_in_seen": false
    }
  }
}

方案B：仅用列表存放激活状态 #

这种方案只保留值为true的状态，用数组列举，未激活的状态直接不出现。

优点 #

• 响应体积小：只存必要的激活状态，带宽占用低，适合移动端或者低带宽场景
• 结构简洁直观：一眼就能看到当前所有激活的状态，不用遍历一堆布尔值

缺点 #

• 语义有歧义：客户端必须预先知道所有可能的状态，否则没法判断某个状态是“未激活”还是“根本不存在”
• 扩展性差：新增状态时，客户端必须同步更新已知状态列表，不然会出现逻辑错误（比如以为新状态没激活，但其实是后端没返回）
• 状态变更难追踪：某个状态从激活变未激活，只是从数组里删掉，日志里看不到明确的“false”标记，排查问题麻烦

示例代码：

{
  "param1": ["visited"],
  "desktop_app": ["installed"],
  "chekpoints": {
    "2021-W43": ["choice_done", "slide_in_seen"],
    "2021-W44": []
  }
}

选择建议 #

• 选方案A：如果业务需要明确所有状态的存在性、后续会频繁新增状态，或者对带宽要求不高
• 选方案B：如果带宽紧张、状态集合基本固定不变，且业务只关心“哪些状态激活了”，不需要处理未激活的情况

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