我花了4小时调试 Google OAuth……然后我删除了该功能（在构建我的第一个 SaaS 时的教训）

Source: Dev.to

计划：让用户从平台发送邮件

一旦后端智能层正常工作，下一步显得很明显。设想的流程：

1. 用户使用 Google OAuth 登录。
2. LeadIt 请求访问 Gmail 的权限。
3. Google 返回访问令牌和刷新令牌。
4. 将这些令牌存入我的 Supabase 数据库。
5. LeadIt 使用 Gmail API 自动发送外联邮件。

纸面上看，这很直接。

配置 Google Cloud

我先在 Google Cloud 控制台（GCP）里完成所有配置：

• 创建了一个 Google Cloud 项目。

• 启用了 Gmail API。

• 配置了 OAuth 同意屏幕。

• 生成了客户端 ID 和客户端密钥。

• 添加了重定向 URI，例如：

  http://localhost:3000/api/auth/callback/google

• 使用 https://www.googleapis.com/auth/gmail.send 等范围添加了 Gmail 权限。

此时一切看起来都正确。

认证成功… 但令牌没有

OAuth 重定向成功，客户端 ID 有效，同意屏幕显示，认证完成。然而 Gmail 提供者的令牌从未存入我的数据库，导致：

• 没有 Gmail API 调用。
• 没有邮件发送。
• 没有自动化。

因此，尽管认证成功，这个功能实际上是无用的。

四小时调试螺旋

数据库层

• 数据库连接。
• 用户表结构。
• 提供者令牌字段。
• 行级安全策略。

一切看起来都正常。

服务端逻辑

• OAuth 回调处理器。
• 解析提供者令牌。
• 将令牌插入数据库。
• 会话处理。

未发现问题。

客户端流程

• 认证会话。
• 提供者响应。
• 令牌可用性。

同样，没有异常。

Google Cloud 配置

• OAuth 范围。
• 重定向 URL。
• Gmail API 权限。
• 客户端 ID 配置。

全部看起来没问题。

领悟

经过数小时的调试，我问了一个简单的问题：LeadIt 的真正核心是什么？

答案不是 Gmail 自动化。核心是：

• 发现公司。
• 分析它们的网站。
• 检测机会信号。
• 生成 AI 外联消息。

自动发送邮件有用，但并非必需。

创始人决定：砍掉功能

与其在 OAuth 的复杂性上继续投入时间，我把邮件自动化功能从 MVP 中移除。产品现在聚焦于：

• 公司搜索。
• 网站分析。
• 潜在客户发现。
• 潜在客户评分。
• AI 生成的外联消息。

用户可以直接复制生成的消息并手动发送。

简化认证

我还决定在 MVP 中用简单的 Next.js 认证取代复杂的 OAuth。OAuth 带来了大量的移动部件：

• 客户端 ID。
• 重定向流程。
• 令牌存储。
• 刷新令牌。
• 权限范围。

所有这些都消耗开发时间和调试精力。

着陆页进展

在后端工作继续进行的同时，我一直在构建 LeadIt 的着陆页，并自问：

• 产品理念是否合理？
• 价值主张是否清晰？
• 你会尝试这样的工具吗？

早期反馈非常宝贵。

今天真正教会我的事

• 快速交付。
• 避免不必要的复杂性。
• 必要时砍掉功能。

有时最聪明的工程决策不是修复问题，而是彻底移除问题。

最后感想

打造你的第一个 SaaS 往往很混乱。如果你现在正在构建某个东西，我很好奇：你是否曾花了数小时调试一个功能…却最终发现根本不需要它？