Google Apps Script Web App 的入站 HTTP 请求有每日上限吗？

目前，Google 官方配额表没有列出 Web App 的 doGet/doPost 每日入站请求总数上限。免费账户每天 20,000 次的 URL Fetch calls 配额针对脚本发出的请求，不适用于外部客户端调用 Web App。不过，这也不足以证明免费 Gmail 账户能长期可靠地处理每天约 100,000 次请求。官方配额说明

没有公布每日上限，是否代表可以无限调用？

不能这样理解。即使不使用 UrlFetchApp，进入处理函数的请求也要执行脚本，受执行限制约束。官方当前列出的相关限制包括：

官方还列出了短时间调用过多时出现的错误，例如 Script invoked too many times per second for this Google user account.，但没有给出可用于计算 Web App 安全吞吐量的固定每秒速率。因此，不能根据这些数字推导出有保证的每日接收容量。配额本身也可能调整。执行限制与异常说明

部署时也需要确认执行身份。如果选择“以我身份执行”，请求会以部署者身份运行，不能把不同客户端当成独立的执行账户来计算额度。Web App 执行身份说明

每天约 100,000 次请求意味着什么？

按全天均匀分布计算：

100,000 / 86,400 ≈ 1.16 次请求/秒

单个客户端如果严格每秒发送一次 GET 请求，全天共发送 86,400 次。以每天约 100,000 次估算容量时，还应计入重试或额外客户端产生的流量。

这个平均速率本身无法证明会超限，也无法证明一定稳定。需要区分两个时间：

• 脚本内部处理耗时：题目给出的不到 50ms。
• 客户端端到端耗时：从发出请求到完整收到响应，包括网络、平台调度及可能的重定向。

如果客户端每隔一秒启动新请求，而上一次请求尚未结束，未完成的请求就可能累积。即使单次处理很快，也仍需验证实际延迟、失败率和突发流量。

另外，配额表中免费账户每天 90 分钟的 Triggers total runtime 有明确的触发器适用范围，不能直接当作所有 HTTP 调用共享的每日运行时间预算。每日配额表

CacheService 会影响中继可靠性吗？

会。缓存可靠性与请求次数限制是两个独立问题。

CacheService 中的数据可能在设置的过期时间之前消失。官方规定的显式过期时间最长为 21,600 秒，即 6 小时；读取不到对应键时，get() 返回 null。Cache API 说明

如果 POST 接收 webhook 后只把事件放进缓存，等待 GET 轮询取走，事件就可能在读取前消失。即使请求成功返回，也不能认定事件已经可靠保存。

处理方式需要根据业务要求确定：

• 如果只提供可丢失的临时状态，客户端应能处理缓存缺失，并区分“数据不可用”和“没有新事件”。
• 如果每条 webhook 都必须送达，应使用持久化存储或消息队列，并设计确认、重试和去重机制。仅靠缓存无法满足这一要求。

应该怎样验证当前部署？

先通过正式部署的 /exec 地址检查完整 HTTP 链路，再逐步增加到目标请求频率。若使用 ContentService 返回数据，客户端需要支持跟随重定向。Content Service 重定向说明

下面的命令用于检查一次 GET 请求的最终状态和总耗时，不是容量测试：

curl -L --silent --show-error \
  --output /dev/null \
  --write-out 'status=%{http_code} total=%{time_total}s\n' \
  'https://script.google.com/macros/s/YOUR_DEPLOYMENT_ID/exec'

持续验证时，建议记录：

1. 客户端成功率、超时率，以及 P95、P99 响应时间。
2. Apps Script 执行记录中的失败原因和同时执行情况。
3. webhook 从接收到被客户端确认的完整过程，包含缓存缺失、重复投递和客户端断线后的恢复。

轮询端尽量等当前请求结束后再安排下一次请求；失败时采用带随机抖动的退避重试，避免固定频率的重试进一步放大流量。对于每天只有 5 到 20 次 webhook 的场景，也可以评估是否需要全天每秒轮询。

免费 Gmail 账户能否满足这组负载，需要在实际部署条件下验证。现有文档没有给出“每天 100,000 次入站请求可稳定运行”的容量承诺；一次测试成功也只能说明测试期间的表现。如果业务要求 webhook 不丢失，首先需要解决缓存无法可靠保存事件的问题。

备注：内容仅供参考。