Google 日历 API 设有配额，以确保所有用户都能公平地使用 Google 日历 API。使用 Calendar API 时，需要考虑三个重要的限制：
- API 用量配额是按项目和每个用户来实施的。如需了解详情，请参阅下一部分。
- Google 日历的一般用量限制：避免达到 Google 日历使用限制。
- 操作限制：您随时可能受到速率限制。例如，如果您尝试连续向单个日历写入内容。
Calendar API 用量配额的类型
强制执行两种类型的配额：
- 每个项目每分钟：这是您 Google Cloud 项目发出的请求数量。
- 每位用户每个项目每分钟的请求次数：这是您的 Cloud 项目中任意特定用户发出的请求数量。此限制旨在帮助您确保在用户之间公平地分配使用量。
配额按每分钟计算，因此使用滑动窗口，因此一分钟内超出您的每分钟配额的流量迅速激增会导致下一个窗口期内的速率限制，从而确保您的用量平均不超出配额。
如果超出任一配额，您将受到速率限制，并且会在查询中收到 403 usageLimits 状态代码或 429 usageLimits 状态代码。如果出现这种情况，您可以采取以下措施：
申请增加配额
如需查看或更改项目的用量限额，或申请增加配额，请执行以下操作：
- 如果您的项目还没有结算账号，请创建一个。
- 在 API 控制台中访问 API 库中的“已启用的 API”页面，然后从列表中选择一个 API。
- 如需查看和更改配额相关设置，请选择配额。如需查看使用量统计信息，请选择使用量。
使用指数退避算法
如果您希望降低请求速率，我们将返回 403“usageLimits”响应或 429 响应（请参阅完整的错误文档）。这不是严重错误，我们希望您在较短的时间间隔后重试请求。如果请求仍未送达，我们会再次询问，依此类推。为使该机制正常运行，请求之间的延迟必须随着时间的推移而增加。
通常，您应该使用截断指数退避算法；Cloud Storage 文档详细介绍了其工作原理和首选算法。如果您使用的是 Google 客户端库，系统通常会为您处理此操作；请参阅您的库文档。通常，您应该使用库实现，而不是自行编写。
随机选择流量模式
日历客户端很容易因多个客户端同时执行操作而导致流量模式出现高峰。例如，日历客户端的常见错误做法是在午夜执行完全同步。这几乎肯定会导致超过每分钟配额，并导致速率限制和退避。
为避免出现这种情况，请确保您的流量尽可能分散在全天各个时段。如果您的客户端需要执行每日同步，请让客户端确定一个随机时间（每个客户端的不同）。如果您需要定期执行操作，请将间隔时间设置为 +/- 25%。这会更均匀地分配流量，并提供更好的用户体验。
使用推送通知
一种常见的使用场景是，每当用户日历发生变动时都执行相关操作。这里的反模式是反复轮询感兴趣的每个日历。这会很快用完您的所有配额，例如，如果您的应用有 5,000 个用户，并且每分钟对每个用户的日历进行一次轮询，那么甚至在工作完成之前，每分钟的配额必须至少达到 5,000 次。
服务器端应用可以注册接收推送通知，这样我们就会在发生关注事件时通知您。这些功能需要完成更多设置工作，但可以显著提高配额的使用效率，并提供更好的用户体验。请务必指定您要接收通知的 eventType。如需了解详情，请参阅推送通知。
对服务账号进行适当核算
如果您的应用使用全网域授权执行请求，则默认情况下，服务帐号的计费依据为“每位用户每个项目每分钟”配额，而非您模拟的用户。这意味着服务帐号可能会用尽配额并受到速率限制，即使它可能是在多个用户的日历上运行，也是如此。为避免这种情况，您可以使用 quotaUser 网址参数（或 x-goog-quota-user HTTP 标头）指明将向哪个用户收费。这仅用于计算配额。如需了解详情，请参阅 Cloud 文档中的限制每个用户的请求数。
测试配额限制处理方式
为了确保您的应用能够在实际操作中妥善应对达到配额限制的情况（例如，使用指数退避算法重试），并最大限度地减少对用户的潜在干扰，我们强烈建议您在真实环境中测试此场景。
为了避免此类测试对您的实际应用使用造成干扰，我们建议您在 Google API 控制台中注册一个单独的仅供测试用的项目，并采用与生产项目类似的方式配置该项目。然后，您可以为此项目人为设置较低的配额，并观察应用的行为。
价格
对 Google Calendar API 的所有使用均免费。超出配额请求限制不会产生额外费用，并且系统不会向您的帐号收费。