这个怎么运作

Google Drive（独立）Web 应用程序可自动从 Drive 下载（轮询）文件到用户的本地 PC（下载文件夹）。

DriveApp 提供搜索和下载文件的机制。但是，由于 Google Apps 继承了客户端/服务器架构，下载机制存在一些严重的限制。 （没有谷歌的错误）

服务器端 DriveApp 不提供下载到本地 PC 的直接功能，因为服务器没有客户端的概念，将文件下载到服务器本身就没有意义。

服务器端代码需要一种机制来向客户端代码提供文件数据或文件链接。提供了这两种机制，但前者的数据仅限于客户端代码直接使用。客户端没有将数据保存到本地 PC 的机制。因此，它可用于在网页本身上显示数据。

第二种机制允许传回脚本（本身）的 url 或 Drive 文件的 url。Drive 文件 URL 不是很有用，因为无法在客户端浏览器中直接使用它来下载文件。将此 URL 置于锚点（并单击它）只会导致打开但实际上没有执行任何操作的网页（除非可能在线查看该文件）。

这留下了脚本网址。但是脚本 url 仅提供脚本而不提供文件。

要启动下载，必须使用 ContentService createTextOutput 从服务器端脚本的 doGet / doPost 函数返回 Drive 服务中的文件，完全如 Google 在线指南中所示。但是，这意味着 doGet / doPost 返回的结果在网页上不能有其他 UI 元素。

这给我们留下了一个非常缺乏吸引力的解决方案。没有用户 UI 元素下载页面的空白网页，关闭，需要在需要另外下载时手动打开。

显然，另一个托管网页可以提供 UI 和 Web App 下载脚本的链接来解决此问题。

该脚本使用 Dr. Jekyll 和 Mr Hyde 方法来解决此问题。

如果打开的脚本没有 GET 参数（doGet），则默认显示表单。这将是用户首次打开发布的应用程序时的情况。此示例中提供的表单非常简单。

如果使用参数 servefile = true 打开脚本，则脚本将表现为 Drive 文件下载。

客户端 javascript 包含一个轮询机制（事件计时器 setInterval），它定期调用服务器端脚本以检查另一个要下载的文件的可用性。

当服务器端脚本执行时，如果找到与搜索条件匹配的任何 Drive 文件*，则返回脚本本身的 url，并附加参数：

？servefile = TRUE＆ID = the_id_of_the_google_drive_file

（*这个简单示例中的搜索条件被硬编码到服务器端脚本中。如果需要，可以很容易地从客户端传递到服务器。）

此信息通过已识别的 withSuccessHandler 机制以字符串形式返回给客户端。

然后，客户端 java 脚本使用此返回的信息更新隐藏锚点的 HREF，然后自动单击锚点。

这会导致启动另一个 app / script 调用。当应用程序的新调用启动时，doGet 将检测 servefile 参数，而不是返回用户界面，它将返回文件到浏览器。返回的文件将是由先前由上述搜索返回的提供的 ID 参数标识的文件。

鉴于具有提供的 ID 的文件仍然存在，它将被下载并且应用程序的新调用将关闭，而第一次调用将重复此过程。

如果用户/测试人员在等待计时器时不耐烦，则在简单界面上提供一个按钮，但不需要该按钮，否则可以将其移除。

当然，可以扩展简单形式以在需要时提供更丰富的用户界面。例如提供文件搜索条件。