LinkedIn API数据差异：同一公司帖子双端点返回数据不一致
我之前也碰到过LinkedIn不同API端点返回数据不一致的情况，尤其是点赞这类互动统计数据，结合你的场景，大概率是以下几个核心原因导致的：
统计逻辑与口径差异
你调用的/companies/4822304/updates/key=UPDATE-c4822304-6378756278751109120/likes?format=json是直接拉取该帖子的实时点赞用户列表，返回的是实际可查询到的点赞用户数量；而historical-status-update-statistics是LinkedIn的聚合统计端点，它的like-count可能包含了特殊场景的计数——比如系统缓存的临时点赞记录、匿名互动的统计（这类不会显示在点赞列表里），甚至是LinkedIn内部定义的"隐性互动"（比如用户快速划过但系统判定为兴趣的行为），两者的统计逻辑从根上就不一样。数据同步延迟
LinkedIn的实时数据端点（比如单个帖子的点赞列表）和历史统计端点的更新频率完全不同。实时端点会即时同步用户的操作行为，而历史统计端点是按你指定的time-granularity=day进行批量计算和更新，通常存在几小时甚至一天的延迟。如果你的两个请求间隔时间较短，很可能因为统计数据还没完成同步，导致结果不一致。时间范围参数的遗漏/错误
注意你提供的历史统计请求里star...是不完整的，大概率是start-time参数没写完。如果这个参数设置的时间范围没有覆盖帖子发布到当前的完整周期，比如只统计了某一天的数据，那自然会和实时端点的累计点赞数产生差异。统计指标的定义偏差
仔细核对两个端点的指标说明：实时点赞端点返回的是主动点击点赞按钮的用户数，而历史统计里的like-count可能包含了LinkedIn算法判定的等效互动（比如用户通过系统推荐卡片进行的点赞操作，这类在列表里可能不会完全展示），两者的指标定义本身就有区别。
验证与解决建议
- 补全并确认
historical-status-update-statistics请求的start-time和end-time参数，确保时间范围完全覆盖帖子发布到当前的所有天数； - 等待24小时后重新对比两个端点的数据，看是否是延迟导致的临时差异；
- 调用单个帖子的专属统计端点
/companies/4822304/updates/key=UPDATE-c4822304-6378756278751109120/statistics?format=json，对比这个端点的like-count和历史统计数据，如果一致，就说明是实时点赞列表和聚合统计的逻辑差异导致的，属于正常现象。
内容的提问来源于stack exchange，提问作者Priyanshu Agarwal
