如何从Lovable迁移到Mythex（代码、数据和域名）

要从Lovable迁移到Mythex，先通过Lovable的GitHub集成把代码导出来，然后通过关联仓库或导入压缩包，将代码带入Mythex项目，重新添加你的密钥，并在发布前于预览中测试。前端通常无需改动即可迁移。真正需要决定的是后端：继续使用你现有的Supabase项目，还是把数据迁移到别处。

本指南按顺序讲解整个迁移过程，并如实说明哪些部分需要花功夫。

开始之前：哪些内容会迁移

Lovable应用由几个部分组成，每个部分的迁移方式各不相同。

先为你自己的应用写出这张表格。只需十分钟，就能避免大多数意外。

第一步：把代码从Lovable中导出

Lovable的文档（截至2026年9月）描述了两种导出方式：

• GitHub同步。 Lovable可以将你的项目导出到GitHub并进行双向同步，其文档列出所有套餐都支持github.com。在Lovable中连接GitHub，你的代码就会进入一个你拥有的仓库。请注意，Lovable每次只同步一个分支。
• 下载代码库。 在Lovable的付费套餐中，你可以直接从项目设置 → Git下载代码。

对于迁移而言，GitHub是更好的途径：你可以获得完整的历史记录，并且在测试新环境时仍能继续同步。最新步骤请参见Lovable的GitHub集成文档。

离开Lovable之前，打开仓库并查找：

• .env或.env.example文件，其中列出了应用需要的环境变量
• supabase/文件夹，其中可能包含数据库迁移和Edge Function代码
• package.json中的脚本，它们说明应用如何构建和运行

第二步：决定如何处理后端

这是最重要的选择。Lovable应用通常使用Supabase来管理数据库和登录，可能是通过你自己连接的Supabase项目，也可能是通过Lovable Cloud。

方案A：继续使用你自己的Supabase项目

如果你的应用已经在与你自己的Supabase项目通信，这是最简单的途径。应用代码将继续调用相同的Supabase地址和相同的密钥，因此你的数据、用户和文件都保持原样。你只需迁移前端。

方案B：从Lovable Cloud迁出

如果你的应用使用的是Lovable Cloud，Lovable提供了数据库导出功能，位于更多 → Cloud → 概览 → 高级设置。根据Lovable的文档（截至2026年9月）：

• 导出内容包含完整的数据库，包括结构和数据，以及用户账户及其密码哈希。
• 不包括存储中的文件、Edge Function代码，也不包括你项目的密钥。登录服务商的设置同样不包括在内。
• 导出支持最大15 GB的数据库，导出文件最大5 GB，并且每24小时只能请求一次导出。
• 没有从Cloud到Supabase的一键迁移；迁移Cloud后端支持的目标是托管版Supabase或自托管版Supabase。

因此，实际做法通常是：把导出内容恢复到你自己的Supabase项目中，在那里重新创建存储桶、Edge Functions和身份验证设置，然后按方案A处理。详细信息请参见Lovable的高级设置文档。

方案C：把所有内容迁移到Mythex的数据库

Mythex可以为项目提供专用的Postgres数据库。把数据迁移过去是可行的，但这意味着要重写应用中每一处使用Supabase客户端库的代码，而且Mythex没有内置的终端用户登录，因此你还需要接入一个独立的身份验证服务商。这是对后端的真正重建，而不是迁移。如果需要，可以之后再做，前提是应用已经在Mythex上使用Supabase正常运行。

第三步：把代码导入Mythex

在Mythex中新建一个空项目。然后任选以下一种方式：

• 导入压缩包。 打开项目设置 → 导出 → 导入到此项目，上传.zip、.tar.gz或.tgz文件。GitHub的Download ZIP按钮提供的文件可以直接在这里使用。
• 连接GitHub并拉取。 在项目设置中连接GitHub，关联仓库并拉取。GitHub同步是Pro功能。

导入会替换项目的文件，因此请使用一个空项目。压缩包中的所有.env文件在导入时都会被移除，因此不会意外带入任何密钥。导入成功后，Mythex可以打开一个新的聊天，由智能体安装依赖、弄清如何运行应用，并让预览正常工作。你可以像其他聊天一样引导它。详情参见导入之后。

如果预览没有自动启动，请这样询问：

这个项目是从Lovable导出的。它是一个使用Supabase的React + TypeScript + Tailwind应用。请安装依赖，根据package.json找出开发命令，并让预览运行起来。目前先不要修改任何应用代码。

第四步：重新添加你的密钥

打开项目设置 → 密钥，添加应用所需的每一个值。对于基于Supabase的应用，通常需要Supabase项目的URL以及公开的（anon或publishable）密钥。名称可以从.env.example中获取，或从代码读取它们的位置获取。

两条规则：

• 只有公开密钥才能放在前端变量中。在Vite应用中，任何带VITE_前缀的内容都会被编译进每位访问者都会下载的JavaScript中。
• 切勿把Supabase的service role密钥放进前端代码。如果服务端函数需要它，就让它留在服务端。

然后让智能体确认应用确实读取了这些值：

检查这个应用读取了哪些环境变量。列出项目密钥中尚未设置的变量，并且不要打印它们的值。

我们关于环境变量和密钥的指南解释了公开值与私有值之间的区别。

第五步：在切换之前先测试

你的Lovable应用仍在线上运行，因此不必着急。在预览中针对真实流程测试Mythex版本：

• 注册、登录、退出，以及重置密码
• 创建、编辑和删除一条记录
• 上传文件（如果你的应用支持）
• 任何调用Edge Function或第三方API的功能

Supabase身份验证有一个容易被忽略的设置：允许用于登录和重置密码邮件的重定向URL。请把你的Mythex预览地址和已发布地址添加进去，否则登录会跳转回旧域名。

Mythex的/test命令可以让智能体像用户一样点击你的预览，并报告损坏的流程。我们关于上线前测试应用的指南提供了更完整的清单。

第六步：发布并迁移域名

一切正常后，从工作区发布，即可获得<slug>.mythex.app地址。在该地址上再次测试，因为已发布的应用是你项目的一个独立快照。

在Pro套餐中，你可以绑定自己的域名。在你的域名服务商处更新DNS记录，将新地址添加到Supabase允许的重定向URL中，然后再下线Lovable版本。我们关于绑定自定义域名的指南逐步讲解了DNS设置。

常见错误

• 同时迁移数据库和前端。 先迁移前端，证明它能与现有后端正常工作，然后再决定数据的去向。
• 忘记Edge Functions。 如果应用调用了Supabase Edge Functions，它们要么继续留在Supabase上，要么需要重写为服务端代码。它们无法在Vite前端中运行。
• 把service role密钥粘贴进前端。 任何打开开发者工具的人都能借此获得数据库的完全访问权限。
• 缺少身份验证重定向URL。 登录在预览中正常，到了正式域名上却失败。
• 在测试已发布的URL之前就切换DNS。 请先测试mythex.ai地址；撤销DNS更改需要时间。
• 导入到一个已有工作内容的项目中。 导入会替换文件。请使用一个全新的项目。

什么时候继续使用Lovable更合适

请诚实地审视自己为什么要迁移。Lovable提供预览中的可视化直接编辑，以及由Lovable Cloud提供的产品化后端，而Mythex两者都没有。如果你日常依赖这些功能，迁移带来的损失可能大于收益。如果你希望在聊天旁边有一个真正的代码编辑器和终端，希望构建和托管共用一个积分余额，或者想运行不同的技术栈，那么Mythex会更适合你。我们的Lovable替代方案指南以及Mythex对比Lovable页面会更详细地进行比较。

迁移清单

• 列出了应用的每个部分：代码、数据库、用户、文件、函数、密钥、域名
• 代码已同步到你拥有的GitHub仓库
• 已确定后端方案（保留Supabase，或从Lovable Cloud导出）
• 代码已导入空的Mythex项目，预览已运行
• 密钥已重新添加；没有将私有密钥放入VITE_变量
• 已为新地址更新身份验证重定向URL
• 注册、登录、核心数据流程和上传已在预览中测试
• 已发布，并在mythex.ai地址上重新测试
• DNS已迁移；只有在确认新应用正常后才下线旧应用

关于Mythex这一侧的内容，请参见文档中的GitHub、导出与导入。

常见问题