从 Lovable Cloud 迁移到 Supabase 不仅仅是简单的数据库导出与恢复。迁移后会出现诸多问题，尤其是涉及身份验证、AI 功能和电子邮件服务方面。因此，制定一份全面的检查清单至关重要，这也促成了免费迁移检查器的诞生，该工具可分析 GitHub 仓库。Lovable Cloud 项目包含关键的后台组件，如用于模式变更的'supabase/migrations'、用于边缘函数的'supabase/functions'，以及用于项目配置的'supabase/config.toml'。尤为关键的是生成的类型文件'src/integrations/supabase/types.ts'，它提供了公共表的准确列表，从而揭示模式漂移（schema drift）——即 Cloud UI 中的变更未记录在迁移文件中。迁移过程应优先处理扩展，其次是模式，然后是函数、触发器，最后是数据。需特别关注对'auth.users'的触发器，以防止新用户配置文件出现问题。复制'auth'模式（包括'auth.users'和'auth.identities'及其密码哈希值）至关重要，以确保用户能够使用现有凭据登录。存储迁移尤为棘手，需要编写针对存储 API 的脚本，或使用'rclone'在 S3 端点之间传输文件；存储桶必须使用完全相同的名称和设置重新创建。常见的迁移后故障点包括 Google 登录，旧版项目默认使用 Lovable 的 OAuth 代理。这需要在 Google Cloud Console 中配置自己的 OAuth 客户端，并更新前端调用，改用普通的'supabase.auth.signInWithOAuth'。Lovable 的 AI 网关调用嵌入在边缘函数中，在 Lovable Cloud 外部将失效，需要新的 AI 提供商密钥和 URL。注册邮件也将停止到达，因为新 Supabase 项目的电子邮件服务受到限制；必须使用自定义 SMTP 服务，如 Resend 或 Postmark。此外，定时任务（cron jobs）常被忽视，可能硬编码了旧项目的 URL，继续调用已失效的 Lovable Cloud 实例。该迁移检查器通过模式匹配来自公共 GitHub 仓库的文件来解决这些问题。虽然它快速且无需依赖，但依赖正则表达式进行 SQL 解析，无法检测未在迁移中反映的由仪表板所做的变更。它仅作为检查清单，而非 definitive 审计。对于偏好专业协助的用户，可提供固定价格的迁移服务。