企业官网建设流程全解析

GoLive 供应商选型终极指南：Vercel vs Netlify、Supabase vs Neon，3 步选对你的生产栈

【免费下载链接】golive-skillTake your agent-built product live: hosting, database, domain, email, payments — on your own accounts. Open-source Agent Skill + zero-dependency Node CLI: detect → plan → approve → apply → verify. No GoLive account, backend or telemetry.项目地址: https://gitcode.com/gh_mirrors/go/golive-skill

如果你在用 AI Agent 写应用，GoLive 是一个开源的 Agent Skill + 零依赖 Node CLI：它先检测你的应用需要什么，再规划确切变更，经你批准后在你的自有账号上执行，最后验证什么真正可用——没有 GoLive 账号、后端或遥测。当它问你"选哪个托管、哪个数据库"时，本文给你一份直接的对照答案：Vercel 还是 Netlify，Supabase 还是 Neon，以及 3 步选对的判断方法。

先认识 GoLive：检测 → 计划 → 批准 → 执行 → 验证

选生产栈之前，先理解 GoLive 的工作方式，这决定了"选什么"其实只占部署工作的一小部分。

GoLive 的核心流程是：

1. 检测（detect）：扫描你的package.json、配置文件和源码，判断应用已经在用什么。比如检测到vercel.json就推断托管倾向 Vercel，检测到@supabase/supabase-js就推断数据库/认证倾向 Supabase（规则见 src/detect/providers.ts）。
2. 计划（plan）：生成一份带具体目标账号、项目 ID、资源规格和成本说明的计划。
3. 批准（approve）：任何写操作都必须经你确认计划 ID 才能执行，DNS 写入、删除、生产首次部署各有独立的确认门槛。
4. 执行（apply）：用你本人的登录（vercel login、supabase login等）完成创建、环境变量传递、部署。
5. 验证（verify）：环境一致性、数据库连通性、RLS 探测、域名在线等检查，逐项给出证据和局限。

完整架构见 docs/ARCHITECTURE.md，信任与权限边界见 docs/TRUST.md。

💡 关键原则：GoLive 保持你应用已有的供应商选择，只询问缺失的环节。所以第一步永远是"我已经在用什么"，而不是"哪个最流行"。

选型速查表：1 分钟看懂 4 家

这张表的权威来源是 docs/PROVIDERS.md，其中区分了"已实现的操作"和"哪些经过真实账号验证、哪些只有 mock 覆盖"。

Vercel vs Netlify：托管平台怎么选

选 Vercel 的理由

• 项目与域名全自动化：GoLive 的 Vercel 适配器覆盖项目选择/创建、环境变量按环境分别写入（秘密值为只写的 Sensitive 类型）、部署，以及自定义域名的附加与所有权验证（见 skills/golive/references/vercel.md）。
• 与 Supabase 的黄金组合：官方 README 中记录的第一条真实端到端验证路径就是Vercel + Supabase——供给、环境接线、部署、带认证的 CRUD 和访问隔离都跑通过。
• 自定义域名双验证：Vercel + Porkbun 和 Vercel + GoDaddy 两条自定义域名旅程（附加、DNS 记录写入、所有权验证、HTTPS）都在一次性域名上实测通过。
• 细节省心：GoLive 会自动维护.vercel/project.json保持项目链接同步，并在部署前自动向.vercelignore追加排除块，防止把 GoLive 自己的配置文件上传到生产站。

选 Vercel 要知道的代价

• 无晋级/回滚支持：Vercel 适配器读不到"生产当前实际服务的是哪个部署"，所以release.promote下 GoLive 会明确说"不支持"，回滚要去 Vercel 自己的控制台（docs/PROVIDERS.md 中有对照表）。
• 部署保护别乱关：新项目的生成链接默认要求 Vercel 登录，这是安全特性；如果验证检查发现生产被 SSO 墙挡住，由人来决定如何放行。
• CLI 必须安装：即使使用 Token 认证，vercel deploy也依赖 Vercel CLI 存在。

选 Netlify 的理由

• 支持晋级与回滚：Netlify 是四家中唯一能重新读取"生产正在服务什么"的托管，promote:production和release:rollback可以无重建地把生产指回某个已构建的部署（目前实现 + mock 覆盖，未做 live 验证）。
• 公开访问有专门检查：Netlify 项目可能默认可见性为私有，GoLive 有独立的netlify-public-access检查，用匿名首页请求验证"部署成功 ≠ 匿名可访问"。
• 秘密值处理干净：本地构建模式下，非开发环境的秘密值会被遮蔽；运行期才需要的服务端凭据正好适配这个流程。
• CLI 构建/部署 + 已验证组合：Netlify + Neon 是官方记录的另一条完整端到端路径：创建、环境写入、部署、Postgres 连通、双会话 API 检查和浏览器 CRUD 全部通过。

选 Netlify 要知道的代价

• 自定义域名是引导式（guided）：不像 Vercel 那样全自动，域名附加和 DNS 走引导流程，需要人参与。
• 项目可见性可能需要手动调整：私有项目要在 Netlify 控制台的 Project visibility 里改成"Previews only 私有、生产公开"，GoLive 会明确列出该改哪里并等你批准。
• 构建期需要原始秘密值的应用要单独评审远端构建流程——GoLive 不会为了构建通过而降级秘密策略。

托管二选一的判断口诀

🎯要回滚能力和纯静态/轻量站点 → Netlify；要完整自动化（含域名）、Next.js/React 生态、Supabase 联动 → Vercel。

Supabase vs Neon：数据库怎么选

这是四家中"不对等"的一组：Supabase 是数据库 + 认证 + RLS的一体化后端，Neon 是纯粹的 Serverless Postgres。

选 Supabase 的理由

• 应用需要登录系统吗？那就基本是它。Supabase Auth 提供注册、邮件确认、密码策略、会话，GoLive 会自动写入 Site URL 和重定向白名单，并可从golive.yaml应用整份 auth 策略（skills/golive/references/supabase.md）。
• 可选的真实用户旅程验证：开启auth.e2e: true后，GoLive 能跑通"注册 → 邮件确认 → 登录 → 会话"甚至密码找回和双账号数据隔离（auth.recovery、auth.isolation）——这些检查在真实一次性项目上已 live 验证。
• 连接串智能处理：为 serverless 环境写入事务模式（6543 端口）的池化 URL，检测到 Prisma 自动加?pgbouncer=true；直连 URL 用会话模式池化器，避开 IPv6 直连坑。
• 安全验证内置：rls-probe用公共 key 探测表是否可读，配合安全顾问，直接告诉你"公开 key 能读到的表 = 真实泄漏面"。

选 Supabase 要知道的代价

• 免费项目会暂停：约一周不活跃即暂停，恢复需要人工在控制台操作。
• 默认授权规则已变：2026 年后的新项目不再自动向公开角色授权新表，迁移后可能遇到42501 permission denied，需要在迁移里补GRANT+ RLS 策略。
• 内置邮件器限速：注册确认等认证邮件有小时级限速，重度使用建议配 Resend 自定义 SMTP（GoLive 有auth:smtp步骤自动完成，含把邮件限速提到 30/小时）。

选 Neon 的理由

• 你只需要数据库：应用自带认证（Clerk、Auth.js、Firebase 等），不想被绑定任何后端全家桶，Neon 给你干净的 Postgres 连接 URL（池化db.url+ 直连db.directUrl）。
• Serverless 友好：GoLive 的 Neon 适配器创建免费组织下的项目、把连接凭据安全传递到托管环境，并跑只读连通性探测验证数据库和角色（skills/golive/references/neon.md）。
• 已验证组合：Netlify + Neon 完整跑通供给、环境、部署和连通性；Neon 项目本身在golive teardown中作为手动移交项处理（删除需人工确认）。

选 Neon 要知道的代价

• 它不是 Supabase 的替代品：官方明确写明——Neon 不提供 Auth、不提供 Supabase SDK 兼容层、不迁移应用 schema。如果你的代码 import 了@supabase/supabase-js，选 Neon 意味着要重写数据访问层。
• 认证另找：认证轴是独立决策（Supabase / Clerk / Auth.js 等），Neon 路线要自己组合。

数据库二选一的判断口诀

🎯代码里有@supabase/*依赖，或应用需要注册/登录/RLS → Supabase，几乎没有悬念；应用自带认证、只需要一个 Postgres → Neon。

3 步选对生产栈

第 1 步：让 GoLive 检测，尊重现状

运行前先看package.json和配置文件。GoLive 的检测规则（src/detect/providers.ts）本身就是最好的选型依据：

• 有vercel.json/.vercel/project.json→ 托管轴倾向 Vercel；有netlify.toml→ 倾向 Netlify
• 有@supabase/supabase-js或supabase/config.toml→ 数据库轴倾向 Supabase；有@neondatabase/serverless→ 倾向 Neon

规则：已有的选择保留，不因为"听说另一个更好"而迁移。docs/PROVIDERS.md 也强调"托管选择不会悄悄替换 Supabase 应用的数据库或认证"。

第 2 步：用需求清单补齐空缺

对每个未定的轴，回答三个问题：

1. 这个轴的功能要求是什么？（需要 Auth？需要回滚？需要静态托管？）
2. 生态匹配吗？（Next.js/React 全家桶 → Vercel 顺手；纯静态/轻量 → Netlify 够用）
3. 愿意接受哪些代价？（Vercel 的回滚要去控制台；Supabase 免费项目会暂停；Neon 没有 Auth）

第 3 步：看官方验证记录，按"已验证组合"下注

不是所有组合都经过同等强度的实测。README 中明确记录的两条完整 live 路径是：

跨组合（如 Vercel + Neon）有 mock 覆盖，但没有同等的真实验证证据。求稳就选表内组合；需要组合外的搭配，走 GoLive 的引导式（guided）流程——它会优先尝试官方 CLI/API，走不通时给出手动指引，但不保证完成度（docs/PROVIDERS.md）。

选定之后：让 GoLive 替你执行和验证

选型确认后，流程变成：

1. 安装技能（Node.js 20+，npx skills add或 npm 包npx golive@alpha，详见 docs/DISTRIBUTION.md）
2. 在 Agent 里说"用 golive 让应用上线"，它会展示目标账号和计划等你批准
3. 你在独立终端完成vercel login/supabase login等浏览器登录，GoLive 复用登录但不打印任何秘密
4. 批准后执行，verify给出逐项证据；测试资源用完可golive teardown计划拆除（见 docs/RECOVERY.md）

每一步的边界（哪些自动化、哪些留在人手里）都写在各供应商参考文档里，部署前的阅读顺序建议是：docs/PROVIDERS.md → 对应供应商的 reference → docs/VALIDATION.md 核对 live 证据。

选型结论清单

• ✅应用需要登录/注册/RLS→ 数据库轴选Supabase；托管按生态选 Vercel（全自动化 + 域名）或 Netlify（回滚 + 轻量）
• ✅应用自带认证，只要数据库→Neon，注意它不替代 Supabase 的 SDK 与 Auth
• ✅看重晋级/回滚能力→ 托管选Netlify（Vercel 目前不支持，需在控制台操作）
• ✅看重域名自动化和 Supabase 联动→ 托管选Vercel
• ✅求最稳的落地路径→ 直接采用两条已验证组合：Vercel + Supabase或Netlify + Neon
• ⚠️ 无论选谁：生产首次部署、DNS 写入、删除都需要独立确认；GoLive 永不替你购买或注册账号

选对生产栈的本质不是"哪家最强"，而是功能要求 × 现有依赖 × 已验证证据的交集。让 GoLive 的检测先说话，再用上面的口诀补上空缺，你的应用离"上线"就只差一次批准。

【免费下载链接】golive-skillTake your agent-built product live: hosting, database, domain, email, payments — on your own accounts. Open-source Agent Skill + zero-dependency Node CLI: detect → plan → approve → apply → verify. No GoLive account, backend or telemetry.项目地址: https://gitcode.com/gh_mirrors/go/golive-skill