我正在尝试收集作为给定文件夹后代的所有文件和文件夹。
为此，我使用带有q="'FOLDER_ID' in parent" and trashed=false的file.list（），其中FOLDER_ID是我感兴趣的文件夹的ID。当我处理结果时，我会跟踪从此返回的所有文件夹请求然后使用q参数中的新文件夹重复files.list（）调用。我使用or在一个请求中组合了多个文件夹，并继续重复此操作，直到没有返回新文件夹。
示例：
初始请求：q="('FOLDER_ID' in parent) and trashed=false"
所有后续请求：q="('FOLDER_ID_1' in parent or 'FOLDER_ID_2' in parent or 'FOLDER_ID_3' in parent ...) and trashed=false"
（有关如何创建查询的详细信息，请参阅Drive REST API - Search for Files）
有时这会返回它应该的所有文件夹，有时会遗漏一些文件夹。如果我删除q参数，则不会发生这种情况，因为每个文件和文件夹都会被返回，没有一个丢失。
经过一些测试/试验和错误，我发现如果我没有收到我应该的所有文件夹，发送没有q的请求似乎“修复”了问题。下次我运行我的应用程序并使用q时，会返回所有正确的文件夹。
其他信息：
这不是权限问题，我使用drive.readonly
这不是pageSize问题，因为我为此尝试了不同的值并获得了不同的结果。
这不是pageToken问题，因为我确保在给定nextPageToken时再次发送请求。
我在一个文件夹上运行它，该文件夹中有少量4,000个后代文件夹，其中有少量25,000个后代文件。
我觉得这必须是与在单个请求中使用q参数中的多个文件夹相关的错误，考虑到我可以执行完全相同的过程并且看起来会随机获得不同的结果。
答案 0 :(得分：0)
我建议你放弃你采取的方法。对Drive进行如此多的调用将需要永远，并可能会给你配额问题。
简单地获取单个查询中的所有文件夹，然后构建您感兴趣的文件夹ID的内存层次结构要简单得多。然后运行第二组查询以获取这些父项的文件。
或者，如果这些文件是由应用程序创建的，请将它们作为您可以查询的公共虚拟父文件夹的所有子项。
答案 1 :(得分：0)
在查找给定用户拥有的所有文件时，我发现了类似的问题，例如：
'example.user@company.com' in owners and trashed=false
我有大约5000个文件，通常我可以通过分页遍历所有文件。然而有些日子（比如今天）我只得到上述查询的＆lt; 100结果。当我重写我的代码以获取给定父ID的文件然后递归遍历子文件夹时，我将获得所有文件。之后原始查询也会再次成功。
看起来谷歌驱动器服务器上的某种缓存问题对我来说。