使用Google Calendar API未收到Push-Notifications的技术求助

我之前也踩过Google Calendar推送不生效的坑，结合官方要求和实际排查经验，给你梳理几个关键的排查点：

1. 先确认Webhook端点的基础可达性 #

• 必须确保你的webhook地址是公网可访问的HTTPS端点，Google只支持推送到443端口的HTTPS地址，HTTP或者非标准端口都会被拒绝。可以用curl -X POST https://你的webhook地址测试，确保服务能正常接收请求并返回200 OK。
• 检查防火墙、WAF或反向代理规则：Google的推送请求会携带X-Goog-*系列请求头，不要拦截带这些头的请求，也不要设置过短的超时时间（Google要求端点在10秒内响应）。

2. 核对Watch请求的参数准确性 #

• 确认address参数完全匹配你已验证的域名：比如你验证的是yourdomain.com，那webhook地址必须是https://yourdomain.com/xxx，不能用IP地址、未验证的子域名（除非子域名单独验证过）。
• 检查id参数的唯一性：每次创建订阅时最好使用不同的id，避免重复订阅导致的推送异常；token参数如果自定义了，要确保格式合法（比如不要包含特殊字符）。

3. 验证域名验证的有效性 #

• 登录Google Console的域名验证页面，确认对应域名的状态是已验证：如果是用HTML文件验证，确保文件没有被删除或路径变更；如果是DNS验证，确认DNS记录已生效（可以用nslookup检查）。
• 注意：根域名验证会覆盖所有子域名，但如果你的webhook用了子域名，最好直接验证该子域名，避免潜在的权限问题。

4. 查看日志找线索 #

• 检查Google Console的Calendar API日志：在API详情页的「日志」板块，查看是否有推送失败的记录，里面会明确标注错误原因（比如端点不可达、返回非200状态码、超时等）。
• 查看你的webhook服务日志：确认是否收到过Google的请求——哪怕是错误请求，也能证明Google尝试过推送，缩小排查范围。

5. 权限与订阅状态检查 #

• 确认应用权限范围：调用calendarList.watch需要至少calendar.readonly权限，确保你的OAuth2令牌包含了正确的范围；同时要确认用户已授权应用访问目标日历。
• 尝试重新创建订阅：调用channels.stop接口终止现有订阅，再重新调用calendarList.watch创建新的订阅，避免旧订阅因状态异常导致的推送失败。

6. 手动触发测试 #

• 手动修改目标日历（比如添加、编辑或删除一个事件），等待5-10分钟（Google推送可能有延迟），观察是否收到通知。
• 如果还是没收到，可以用Google的推送测试工具（在Calendar API文档里有内置测试功能）模拟推送请求，验证端点是否能正常处理。

内容的提问来源于stack exchange，提问作者dvelopp