我们的应用程序需要用户文件和文件夹的完整列表。我们使用files.list()viaJavascript库（与官方给出的代码基本相同API reference）。
我们使用“ drive.files”范围。
检查对列表的响应，我们发现某些文件总是丢失。我做了各种测试来理解这个问题：
- 这些文件显然存在。它们出现在 中
Google Drive Webapp，如果我通过 ID 明确请求它们，我可以通过 API 毫无问题地获取它们。 - 它是可重现的，总是丢失相同的文件。
- 它不是暂时的。一天后我尝试了，但仍然缺少相同的文件。我知道 API 中有一些奇怪的效果会在一段时间后消失，但不是这个。
- 这不是一次性的事情（例如在上传过程中出现了一些奇怪的事情）。如果我再次使用完全不同的 Google 帐户重复文件丢失。在一个测试中的一小部分 147 个上传的文件中，有 4 个被
files.list调用丢失，在另一个帐户上使用相同的 147 个文件的另一个测试中，有 23 个文件丢失。 - 它仅在我使用
drive.files范围时发生。如果我放宽范围，drive所有文件都将返回。如果查看 Google Drive Webapp 中的“详细信息”，那么丢失的文件也会显示为我们的应用程序创建的。因此，它们似乎并没有以某种方式失去起源。 - 当我指定搜索查询时也会发生这种情况。如果我使用搜索词“q: modifiedDate > '2012-06-04T12:00:00'” 调用 files.list，它也应该返回所有文件，那么相同的文件会丢失。
- 我重新实现了与 API 的纯 REST 调用相同的事情，以排除这是 Javascript 库的问题。错误仍然存在。
更新：我可以将其归结为分页和maxResults参数的问题。如果我使用不同的值，API 会返回不同数量的项目：
我得到maxResults=100100+100+7=207。
我得到maxResults=9999+99+28=226。
我得到maxResults=101101+101+0=202。
最后一个结果很有趣，它告诉我nextLink还有更多结果，但最后一个响应中的 items 数组实际上是空的。仅此一项就可能表明存在错误。
尽管如此，这只发生在drive.file范围内，计数在整个drive范围内是一致的。
我很高兴听到解决方法的想法。我知道跟踪用户文件的其他方法，例如使用更改提要。我已经在使用它，但对于我们应用程序中的特定部分，我只需要用户帐户中所有应用程序项目的可靠且完整的列表。
另一个注意事项：我们之前在“drive.files”范围内遇到过其他问题（请参阅Listing files with search query returns out-of-scope results (drive.files.list call, using drive.files scope)）。事实证明这是一个简单的解决方法。也许这个问题是相关的。