如何设计JSON格式API响应以表示应用使用组合的统计数据

数据老陈

2026-9-25

两种方案的优缺点对比

第一种逗号分隔键名方案

优点：结构简单，单对象层级浅，已知规则的前提下取值方便
缺点：语义极不清晰，扩展性非常差，你需要额外给调用方约定键名的逗号代表「同时使用」的含义，而且如果后续APP名称本身自带逗号，会直接出现解析冲突，完全不推荐使用。

第二种数组+key数组方案

语义是正确的，调用方不需要依赖额外约定就能理解key数组里的元素是当前统计项覆盖的APP，count是对应的用户数量，也不存在特殊字符冲突的问题，本身可以直接正常使用。

更优的优化方案

可以把字段名改得更表意，避免用模糊的key这类命名，还可以额外加一级外层对象承载元数据，方便后续扩展统计时间、总用户量这类信息，参考实现如下：

{
  "stat_time": "2024-01-01T00:00:00Z",
  "total_users": 61,
  "app_usage_stats": [
    {"apps": ["App1"], "user_count": 10, "usage_type": "exclusive"},
    {"apps": ["App2"], "user_count": 8, "usage_type": "exclusive"},
    {"apps": ["App3"], "user_count": 8, "usage_type": "exclusive"},
    {"apps": ["App1", "App2"], "user_count": 15, "usage_type": "intersection"},
    {"apps": ["App1", "App2", "App3"], "user_count": 20, "usage_type": "intersection"}
  ]
}

优化点说明：

把key改成apps，表意更直接，调用方不需要猜测字段含义
新增可选的usage_type字段，明确当前统计是「仅使用所列APP的独占用户」还是「使用了所列APP的用户（可同时使用其他APP）」，刚好匹配你需求里的「仅使用」「同时使用」两种场景，避免语义歧义
外层用对象包裹，后续新增其他统计维度时不会破坏原有接口的兼容性