要获取最新条目，请使用标准 from-newest-date-descending 下载，该下载将从最新条目开始。您将在 XML 结果中收到一个“继续”标记，如下所示：
<gr:continuation>CArhxxjRmNsC</gr:continuation>`
浏览结果，找出任何新的东西给你。你应该发现要么所有的结果都是新的，要么所有的结果都是新的，然后你已经知道了。
在后一种情况下，你已经完成了，但在前一种情况下，你需要找到比你已经检索到的旧的新东西。通过使用 continuation 来获取从刚刚检索到的集合中的最后一个结果之后开始的结果，方法是在 GET 请求中将其作为c参数传递，例如：
http://www.google.com/reader/atom/user/-/state/com.google/reading-list?c=CArhxxjRmNsC
以这种方式继续，直到你拥有一切。
该n参数是要检索的项目数的计数，可以很好地使用它，您可以随时更改它。如果检查频率是用户设置的，因此可能非常频繁或非常罕见，您可以使用自适应算法来减少网络流量和处理负载。最初请求少量最新条目，比如五个（添加n=5到您的 GET 请求的 URL）。如果所有都是新的，在下一个使用延续的请求中，请求更大的数字，比如 20。如果这些仍然是新的，要么提要有很多更新，要么已经有一段时间了，所以继续以 100 人为一组。
但是，如果我在这里错了，请纠正我，您还想知道，在您下载一个项目后，它的状态是否会由于使用 Google 阅读器界面阅读它的人而从“未读”变为“已读”。
一种方法是：
- 更新在 google 上已在本地读取的任何项目的状态。
- 检查并保存提要的未读计数。（您希望在下一步之前执行此操作，以确保在下载最新项目和检查阅读计数之间没有新项目到达。）
- 下载最新项目。
- 计算您的阅读次数，并将其与谷歌的进行比较。如果提要的阅读次数比您计算的要高，那么您就知道在 google 上已经阅读了某些内容。
- 如果在 google 上已经阅读过某些内容，请开始下载已读项目并将它们与您的未读项目数据库进行比较。您会发现一些 google 说已读取的项目，而您的数据库声明未读；更新这些。继续这样做，直到你发现这些项目的数量等于你的阅读次数和谷歌的阅读次数之间的差异，或者直到下载变得不合理。
- 如果您没有找到所有已阅读的项目，c'est la vie；将剩余的数字记录为“未找到的未读”总数，您还需要在下次计算您认为未读的本地数字时将其包括在内。
如果用户订阅了很多不同的博客，他也很可能对它们进行了广泛的标记，所以你可以在每个标签的基础上做这件事，而不是针对整个提要，这应该有助于减少数据量，因为对于用户没有在谷歌阅读器上阅读任何新内容的标签，您无需进行任何转移。
整个方案也可以应用于其他状态，例如已加星标或未加星标。
现在，正如你所说，这
...这意味着我需要在客户端上保持自己的已读/未读状态，并且当用户登录到 Google Reader 的在线版本时，这些条目已经被标记为已读。这对我不起作用。
真是的。保持本地已读/未读状态（因为无论如何您都保留了所有项目的数据库）或在谷歌中标记已读项目（API 支持）似乎都非常困难，那么为什么这对您不起作用？
然而，还有一个障碍：用户可能会在谷歌上将已读的内容标记为未读。这给系统带来了一些麻烦。我的建议是，如果你真的想解决这个问题，假设用户一般只会接触最近的东西，每次下载最新的几百个左右的项目，检查所有的状态他们。（这并不是那么糟糕；下载 100 个项目让我从 300KB 的 0.3 秒到 2.5MB 的 2.5 秒，尽管在非常快的宽带连接上。）
同样，如果用户有大量订阅，他也可能有相当多的标签，所以在每个标签的基础上这样做会加快速度。实际上，我建议您不仅要按标签检查，还要分散检查，每分钟检查一个标签，而不是每 20 分钟检查一次。如果您想降低带宽，您还可以对旧项目的状态更改进行这种“大检查”，而不是进行“新内容”检查，可能每隔几个小时检查一次。
这有点占用带宽，主要是因为您需要从 Google 下载全文来查看状态。不幸的是，在我们可用的 API 文档中，我看不到任何解决方法。我唯一真正的建议是尽量减少对非新项目的状态检查。