代码乍一看没什么问题。请编辑您的问题，以显示您希望代码加载的数据库中的数据（以文本形式显示，请勿截图）。您可以通过单击溢出菜单 () 中的“导出 JSON”链接来获取此信息

我正在尝试使用 Firebase Cloud Functions 更新文档。我的文档更新不需要考虑现有值，因为它们主要涉及单个文档更新，且风险最小。

我正在尝试使用 Firebase Cloud Functions 更新文档。我的文档更新不需要考虑现有值，并且由于它们主要涉及单个文档更新，冲突风险最小，因此我不会进行事务处理。

问题是，即使一个测试用例也需要大约 3 分钟才能完成。作为一名初级开发人员，我以前从未遇到过 Cloud Functions 的延迟，而且我很难找出问题的根本原因。

以下是我的完整代码及其生成的日志：

const functions = require("firebase-functions");
const admin = require("firebase-admin");

admin.initializeApp();

exports.authenticator = functions.region('asia-northeast1').https.onRequest(async (req, res) => {
  const startTime = new Date().getTime();
  console.log("Function execution started at: ", new Date().toISOString());

  if (req.method !== "POST") {
    console.log("Method Not Allowed");
    return res.status(405).send("Method Not Allowed");
  }

  const data = req.body;

  if (!data || !data.data || !Array.isArray(data.data)) {
    console.log("Bad Request");
    return res.status(400).send("Bad Request");
  }

  res.status(200).send("Processing...");
  console.log("Process started at: ", new Date().toISOString());

  for (const item of data.data) {
    if (!item || !item.phoneNum || !item.authCode) {
      console.log("Invalid data: ", item);
      continue;
    }

    try {
      const updateStart = new Date().getTime();
      console.log("Update started for authCode: ", item.authCode, " at: ", new Date().toISOString());

      await admin.firestore().collection("auth").doc(item.authCode).update({
        phoneNum: item.phoneNum,
        verified: true,
        timestamp: admin.firestore.FieldValue.serverTimestamp()
      });

      const updateEnd = new Date().getTime();
      console.log("Success: ", item.authCode, " at: ", new Date().toISOString(), " Update took: ", (updateEnd - updateStart) / 1000, " seconds");
    } catch (err) {
      console.error(`Error processing ${item.authCode}:`, err);
    }
  }

  const endTime = new Date().getTime();
  console.log("Process ended at: ", new Date().toISOString());
  console.log("Total execution time: ", (endTime - startTime) / 1000, " seconds");
});

函数执行已开始 函数执行已开始于：2024-07-09T21：28：39.167Z

进程开始于：2024-07-09T21：28：39.188Z

已开始对 authCode: 519504f79458497cb8c4709739fbc877 进行更新，时间为：2024-07-09T21:28:39.188Z

函数执行耗时 80 毫秒，完成状态代码：200

成功：519504f79458497cb8c4709739fbc877 于：2024-07-09T21：31：36.657Z

更新耗时：177.469 秒

进程结束于：2024-07-09T21：31：36.957Z

总执行时间：177.79秒

我的 Cloud Functions 的区域是 asia-northeast1 ，而 Firestore 位于 asia-northeast3 。由于担心潜在的区域相关问题，我更改了区域，但之前即使在 us-central1 区域，我也能快速处理更新。

供您参考，我的代码通过来自 Google Apps Scripts 的 POST 请求接收 Gmail 处理的数据。

@FrankvanPuffelen 我进行了一次更新单个文档的测试。提到的 3 分钟实际上只是更新一个文档所花的时间。

您正在发送 res.status(200).send("Processing..."); 更新 Firestore 之前的内容。鉴于此，如果任何文档更新能够顺利完成，您就算幸运了。

将发送响应的代码移动到客户端，直到您更新完所有文档之后。

此外，您现在使用 await 每次调用来更新数据库，这意味着所有更新都是按顺序执行的 - 一个接一个。由于数据似乎不需要这样做，因此如果您并行更新它们，速度会更快。最简单的方法是将所有承诺收集 updateDoc 到一个数组中，然后 await Promise.all(...) 对该数组执行操作。

console.log("Process started at: ", new Date().toISOString());

const promises = [];
for (const item of data.data) {
  if (!item || !item.phoneNum || !item.authCode) {
    console.log("Invalid data: ", item);
    continue;
  }

  try {
    promises.push(admin.firestore().collection("auth").doc(item.authCode).update({
      phoneNum: item.phoneNum,
      verified: true,
      timestamp: admin.firestore.FieldValue.serverTimestamp()
    }));
  } catch (err) {
    console.error(`Error processing ${item.authCode}:`, err);
  }
}

await Promise.all(promises);

const endTime = new Date().getTime();
console.log("Process ended at: ", new Date().toISOString());
console.log("Total execution time: ", (endTime - startTime) / 1000, " seconds");

res.status(200).send("Processing...");

我使用 Promise 实现了并行处理所有请求的逻辑，但出现了同样的问题。因此，我编写了上述代码作为潜在解决方案。实际使用时，我可能会使用 Promise。谢谢你的建议。

此外，提前发送 POST 响应是预期行为。Google Apps Scripts 的函数执行时间配额有限，因此其预期是发送数据然后立即终止。

此外，我还记得一个重要点。在之前的代码中，如果未提前发送 POST 响应，Firestore 文档更新大约需要 5 秒钟。看来 POST 响应可能是导致此问题的原因。有没有办法按预期提前发送 POST 响应，同时确保正确处理 Firestore 更新？

\'提前发送 POST 响应是预期行为\' 这可能是您有意为之，但会改变 Cloud Functions 的响应方式。一旦将完整的响应发送给调用者，它可能会随时终止容器 - 因此您的数据库调用很可能没有机会完成。 --- 如果您不希望调用者等待调用完成，请以这种方式实现 - 不让调用者等待，而不是中止服务器操作。