将 App Check 库添加到应用后，您应在启用 App Check 强制执行之前，确保这样做不会干扰现有的合法用户。
您可以使用 App Check 请求指标来做出此决定。您可以查看整个项目或单个 OAuth 客户端的指标：
如需查看项目的 App Check 请求指标，请打开 Firebase 控制台的 App Check 部分，然后展开 Google Identity for iOS 部分。例如：
如需查看特定 OAuth 客户端的 App Check 请求指标，请打开 Firebase 控制台的 OAuth 客户端页面，并展开与该客户端对应的部分。
请求指标分为四类：
已验证请求是指具有有效 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 对用户有何影响并为后续操作做好准备之后，您便可以启用 App Check 强制执行。