Google Cloud OAuth 应用验证卡住时，按验证层级检查首页、应用名称、隐私政策、网域、联系人和权限，并在没有审核邮件时保留证据升级。
OAuth 验证最磨人的地方，不是报错难懂，而是控制台往往只留下一句“需要开发者采取行动”，邮件却迟迟不来。遇到这种情况，反复点提交通常帮不上忙，还可能把审核时间线弄得更乱。先把问题拆开看：Google 是在核对首页和品牌信息，还是在审查敏感权限；要求回复的邮件发给了谁；审核人员从未登录的环境能不能顺利打开你提交的页面。
在确认原因之前，不要急着删除 OAuth 客户端、轮换密钥或重建同意屏幕。验证卡住通常是资料和沟通链路的问题，并不等于客户端本身坏了。贸然重建反而会影响已经在用的登录流程。
先弄清楚卡在哪一步
进入 Google Cloud Console 的 Google Auth Platform，查看 Branding、Audience 和 Data Access。旧版控制台可能仍显示为“OAuth 同意屏幕”，名称不同，检查逻辑相同。
如果提示首页、隐私政策或网域不符合要求，处理公开页面和域名所有权；如果提示敏感或受限范围，则要解释每个 scope 的用途，并准备能让审核人员复现的演示；如果控制台只显示等待回复，重点应转向项目联系人邮箱和 Google Trust and Safety 的来信。不要把三类问题混在一起改。
首页不是放一个 Logo 就够了
审核人员会把同意屏幕上的应用名称、Logo、开发者信息与首页逐项对照。首页应当公开访问，并清楚说明这是什么产品、由谁提供、用户为什么会授权 Google 账号。应用名如果叫 A，首页却只出现公司名 B，哪怕两者确实属于同一家公司，也容易被要求补充说明。
页面上应当直接看到应用名称、服务用途、联系邮箱和隐私政策入口。不要依赖登录后的控制台页面，也不要把关键信息只画在图片里。审核人员使用无痕窗口访问时，应该仍能看懂产品与授权之间的关系。
隐私政策要回答真实的数据问题
隐私政策不能只是通用模板。它至少要说清楚：读取哪些 Google 用户数据、用来完成什么功能、数据是否保存、保存多久、是否分享给第三方，以及用户如何请求删除。你在 Data Access 中申请的权限，应当能在政策文本里找到对应解释。
例如，只为了完成登录却申请 Gmail 或 Drive 权限，会让审核难度陡增。检查代码和产品流程，删除实际不用的 scope；确实需要的权限，则用产品语言解释功能，而不是只抄一遍技术名称。用户和审核人员都更关心“为什么要读这些数据”，而不是 scope 字符串本身。
网域验证和公开访问要从外部再测一遍
首页、隐私政策、服务条款和回调地址涉及的域名，应归属于已经验证的网域。Search Console 中的所有权状态、Cloud Console 中的授权网域，以及页面最终跳转到的主机名需要一致。常见的疏漏是提交了根域名，链接却跳到另一个子域名；或者页面在公司网络内正常，海外访问却遇到验证码、区域限制或证书链错误。
可以从一台不带登录状态的机器检查响应和跳转：
curl -I https://example.com/
curl -I https://example.com/privacy
预期结果不只是“浏览器里看着能开”：页面应返回 200，HTTPS 证书有效，没有循环跳转，也不会把审核人员送进登录页。若使用 CDN 或安全防护，还要确认不会把 Google 的审核访问误判为机器人。
敏感权限需要一条能复现的证据链
申请敏感或受限权限时，审核材料要让一个不了解产品的人也能照着走通。演示视频从进入产品开始，展示 OAuth 授权、同意屏幕、授权后的具体功能，以及数据在界面中的实际用途。只录授权弹窗，或者只口头解释功能，通常不够。
测试账号、测试步骤和必要前置条件应写在审核说明里。如果功能需要付费、邀请码或特定组织权限，要给审核人员可用的进入方式。每个申请的 scope 都应该在演示中出现；演示不到的权限，往往说明它尚未被充分证明，或者根本不该申请。
邮件没收到，先查联系人而不是继续提交
Google 的补件通知可能发往项目联系人、开发者联系信息或提交验证时填写的邮箱。逐一核对这些地址是否仍有人管理，再搜索发件域名和主题关键词，同时检查垃圾邮件、隔离区和企业邮件网关。团队共用邮箱还要确认外部来信不会被工单规则吞掉。
如果控制台明确显示等待开发者回复，而所有邮箱都找不到来信，使用官方支持入口联系验证团队，并附上 Cloud 项目编号、应用名称、提交日期和当前状态截图。不要在短时间内连续创建新申请；那不会替代原来的沟通线程。
什么时候适合重新提交
修改完成后，换一个没有登录状态的浏览器，从审核人员的角度走一遍：首页能否解释产品，隐私政策能否对应数据用途，授权网域是否一致，测试账号能否进入，视频是否覆盖每个权限。确认这些项目都能通过，再在原申请上补充材料或重新提交。
生产环境已经有人使用时，优先保留现有 OAuth 客户端和回调地址。资料调整可以独立完成；只有确认密钥泄露、客户端配置错误或 Google 明确要求时，才安排客户端变更，并提前准备回滚。审核问题不值得演变成一次登录事故。
联系 Telegram 客服 