Lovable 应用在生产环境出问题？如何让它达到上线标准

为什么我的 Lovable 应用在预览中正常，上线后却出问题？

在预览中，你是唯一的用户，用的是测试数据，点的是你自己做出来的路径。生产环境多了陌生人、真金白银和时间。随之而来的故障很少是因为某一行代码写错了，而是缺少决定：谁可以读取哪一行数据、支付成功但浏览器关闭了怎么办、邮件停止发送时谁会发现。

• 用户之间的数据泄露。除非启用了行级安全并且策略正确，否则 Supabase 会让任何拥有授权的角色读写暴露 schema 中的表。
• 密钥暴露在浏览器中。publishable（anon）密钥可以安全地发布；service role 密钥会绕过所有 RLS 策略，绝不能到达浏览器。
• 支付状态不一致。结账后跳转到成功页面并不能证明已经付款，服务器必须向 Stripe 确认。
• 改动破坏旧功能。没有回归测试，每一条新提示词都可能毁掉上周还正常的功能。
• 静默宕机。没有监控，你的客户会比你先发现问题。

这些问题并非 Lovable 独有。任何快速做出的第一版，不管是人写的还是 AI 写的，往往都有同样的缺口，因为原型的任务是验证想法，而不是经受住陌生人的考验。

Lovable 应用开箱即可上线吗？

部分可以。Lovable 自己的文档说明：连接 Supabase 时，它会为表编写行级安全策略；发布时会运行快速安全扫描（包括数据库审查，例如没有 RLS 的表或对所有人放行的规则、依赖审计和 MCP 服务器检查）；还提供需要手动启动的深度扫描。它也明确表示，扫描无法保证完全安全，不能替代全面的安全审查。

这个说法很公允。扫描能告诉你某条策略存在，却无法告诉你这条策略是否符合你的业务规则，例如团队管理员可以看发票而普通成员不能。这种判断，正是可上线在实践中的含义。

对 Lovable 应用来说，达到上线标准意味着什么？

如何在 Lovable 应用中安全地接入 Stripe 支付？

Lovable 的 Stripe 集成通过边缘函数运行，因此你的 secret 密钥不会进入应用，一次性付款会打开 Stripe Checkout。根据 Lovable 的文档，它默认不配置 webhook：应用直接向 Stripe 查询付款和订阅状态，webhook 可以按需添加。文档还指出，测试模式和正式模式的价格 ID 不同，因此正式上线时需要新的价格 ID。

按需查询状态适用于简单的结账。一旦你开始销售订阅，通常还需要 webhook，因为续费、银行卡扣款失败和取消都发生在用户不在页面上的时候。Stripe 的文档对如何安全地做到这一点有明确说明：

• 用 Stripe-Signature 请求头和你的端点密钥，针对原始请求体校验每个 webhook。
• 预料到重复和乱序的事件。记录已处理的事件 ID，确保每个事件只处理一次（幂等性）。
• 记住，Stripe 会对正式模式下投递失败的事件重试最长三天，因此一个坏掉的端点恢复后，可能会重放好几天的事件。
• 把测试和正式环境的密钥分开。一种模式下的对象在另一种模式下不可见。

我应该自己修、找自由职业者，还是请一支团队？

如果你的应用只有少量用户、不收款、没有敏感数据，你可以借助 Lovable 的安全扫描和 Supabase 的 Security Advisor（它会标记未开启 RLS 的表和对所有人放行的策略），自己把上表逐项过一遍。花一个下午做这件事很值得。

自由职业者或固定价格的救急冲刺，适合已知且有边界的问题：一个坏掉的集成、一次审计。对这类工作，它们往往是更便宜的选择。一次性修复给不了你的是接下来的六个月：测试、发布、升级，以及工作时间以外的事故。这种持续的负责正是我们提供的：Plutonapps 专门把 Lovable 应用推向生产环境并负责运行，我们的外包公司、自由职业者、自招员工与订阅对比列出了每种方式适合的情况。

上线之后会怎样？谁来值班？

上线是工作内容变化的地方，而不是工作结束的地方。需要有人盯着错误、打安全补丁、响应事故，并在不破坏上一个功能的前提下交付下一个功能。在我们的 Starter 方案中，创始人继续在 Lovable 中写提示词，我们的工程师把每个版本构建进真实产品，对每一处改动运行回归测试和视觉回归测试、代码审查和安全检查，每周两次部署到生产环境，每月处理最多五次生产环境紧急事件，并提供工作时间支持。Growth 增加了持续部署和 24/7 支持。详情和价格见我们的价格页面。