因此，根据我的理解（我可能是错误的），我从graph API获得的跳过令牌是一个数字，它指示需要跳过多少电子邮件。
在我们的应用程序中，我们将跳过令牌存储在我们的数据库/内存中，这样我们就可以获取电子邮件的下一页。因此，如果说用户当前的跳过令牌为100，并且在我们向服务器发送带有跳过令牌100的请求之前，该用户删除了10封电子邮件，那么如果仍然使用该100跳过令牌会发生什么？
由于我不确定如何处理这种用户删除电子邮件的情况，因此我们的应用程序的工作方式是：我们总是对跳过令牌做一个减号（例如-10），并检查是否可以找到任何电子邮件或当前响应和上一个响应之间的时间戳重叠，如果没有重叠，我们对跳过令牌做另一个减号。这有点像向后走。我们停止做减法，直到发现重叠。
这有意义吗？到目前为止，我注意到一些跳过令牌的响应将nextLink设置为null，而用户的收件箱中仍然有新电子邮件。另外，我们错过了大约半年的几封电子邮件（这意味着该电子邮件在用户的收件箱中，但未被我们的应用程序提取）。
答案 0 :(得分：2)
“增量查询”（跟踪更改）API可能更适合您的需求。它有效地使您可以在某人的收件箱的更改日志中保留“书签”。
例如除了保留跳过令牌之外，您还可以保留从调用/messages/delta回来的deltaLink。当您再次使用deltaLink调用API时，您将获得自上次调用API +新的deltaLink以来的一系列更改。这使您可以与正在监视的收件箱中正在进行的更改保持“同步”。
API参考文档在这里： https://docs.microsoft.com/en-us/graph/delta-query-overview