LinkedIn Shares API v2返回乱序内容及分页逻辑疑问

我完全懂你这种文档描述和实际行为不一致的挫败感！LinkedIn的Shares API有时候确实会有这种让人摸不着头脑的小坑，咱们一步步拆解排查，看看问题出在哪：

1. 显式指定排序参数，避免默认值异常 #

虽然文档说明默认按创建时间排序，但实际场景中，API的默认行为可能因为版本迭代或特殊场景被覆盖。建议你显式添加排序参数，确保排序逻辑符合预期：

https://api.linkedin.com/v2/shares?q=owners&owners={URN}&sharesPerOwner=1000&sortBy=CREATED&sortOrder=DESC

这里sortBy=CREATED强制指定按创建时间排序，sortOrder=DESC确保结果从最新到最旧排列——虽然这两个是默认值，但显式声明能避免很多隐性问题。

2. 不要手动设置start值，改用游标分页 #

LinkedIn v2 API的分页逻辑大多采用游标（cursor）式分页，而非简单的偏移量分页。手动设置start=100/200这种方式往往不生效，甚至会导致排序混乱或数据重复/缺失。

正确的做法是：

• 第一次请求后，查看响应中的paging字段，里面会包含next链接，该链接自带正确的paginationToken和start参数；
• 下一页请求直接复用这个next链接的参数，而不是手动修改start值。

示例响应中的分页字段：

"paging": {
  "count": 1000,
  "start": 0,
  "links": [
    {
      "rel": "next",
      "href": "https://api.linkedin.com/v2/shares?q=owners&owners={URN}&sharesPerOwner=1000&start=1000&paginationToken=abc123"
    }
  ]
}

3. 检查sharesPerOwner的实际上限 #

文档标注的sharesPerOwner=1000可能存在实际限制——LinkedIn API经常会对单次请求的数据量做隐性限制，比如实际最多允许500条。如果超过上限，API会自动截断数据，间接导致分页和排序逻辑混乱。

建议先把sharesPerOwner降到500甚至100，测试排序和分页是否恢复正常，排除数据量过大的影响。

4. 验证所有者URN格式正确性 #

确保owners参数中的URN格式完全正确，比如个人用户的URN应为urn:li:person:XXXXXX（XXXXXX为用户的数字ID）。格式错误会导致API返回非预期的数据集，自然也无法遵循正常排序逻辑。

5. 核对响应中的实际排序字段 #

拿到API响应后，逐条检查每条share的created字段（创建时间戳），确认返回结果是否真的按该字段排序。如果发现排序完全混乱，大概率是API自身的bug，这时候可以去LinkedIn开发者社区反馈问题，或查看是否有其他开发者遇到类似情况。

你可以先按这些步骤逐一排查，尤其是显式指定排序参数和使用游标分页这两点，大概率能解决你的问题。如果还是不行，建议补充完整的请求参数和响应分页字段，方便进一步定位问题。

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