在您将 App Check SDK 添加到您的应用程序之后，但在您启用 App Check 强制执行之前，您应该确保这样做不会干扰您现有的合法用户。
App Check 请求指标屏幕是您可以用来为实时数据库、Cloud Firestore 和 Cloud Storage 做出此决定的一个重要工具。
要查看产品的 App Check 请求指标，请打开 Firebase 控制台的App Check部分。例如：
每个产品的请求指标分为四类：
已验证的请求是那些具有有效 App Check 令牌的请求。启用 App Check 强制执行后，只有此类别的请求才会成功。
过时的客户端请求是那些缺少 App Check 令牌的请求。这些请求可能来自应用程序中包含 App Check 之前的旧版 Firebase SDK。
来源不明的请求是那些缺少 App Check 令牌的请求，并且看起来不像是来自 Firebase SDK。这些请求可能来自使用被盗的 API 密钥发出的请求，或者来自没有使用 Firebase SDK 发出的伪造请求。
无效请求是那些具有无效 App Check 令牌的请求，这些令牌可能来自试图冒充您的应用程序的不真实客户端，或来自模拟环境。
当您决定启用强制执行时，您的应用程序的这些类别的分布应该通知。以下是一些准则：
如果几乎所有最近的请求都来自经过验证的客户端，请考虑启用强制措施以开始保护您的后端资源。
如果近期请求中有很大一部分来自可能已过时的客户端，为避免打扰用户，请考虑在启用强制执行之前等待更多用户更新您的应用程序。对已发布的应用程序执行 App Check 将破坏未与 App Check SDK 集成的先前应用程序版本。
如果您的应用尚未启动，您应该立即启用 App Check 强制执行，因为没有任何过时的客户端在使用中。
下一步
当您了解 App Check 将如何影响您的用户并准备好继续操作时，您可以为实时数据库、Cloud Firestore 和 Cloud Storage启用 App Check 强制执行。