2026一人公司技术架构：后端和部署迁回国内的踩坑记录

程序员阿树
0 阅读16分钟

北京亦庄前阵子挂了块牌子——国内首个 OPC 创新社区。OPC 是 One Person Company 的缩写，直译就是"一人公司"。这个概念过去几年在海外已经跑通了，Pieter Levels 一个人做了 Nomad List 和 Remote OK，ARR 破百万美元；日本那边 Takuya 用 Next.js + Supabase + Claude 独立做 SaaS，案例写进了各种 YC 的推荐读物。

国内最近也开始有人认真做了。V2EX 上有个 41 岁的 Java 老兵发帖讲他第一次出海独立开发，技术栈从 Java 全家桶换成 Next.js。他说的原因很实在——"一个人扛不动那一套重装备"。

但问题来了，如果你的用户在国内，这套海外标准栈还能不能用？

答案是：能用，但会撞墙。

这篇不谈情怀，逐层踩坑——Supabase + Vercel + Stripe 这三样东西到了国内分别卡在哪里，Next.js 继续用、只换底座的话 CloudBase 能不能接住，哪些真省事哪些不如原来，以及什么场景下你压根不该换。

一、一人公司开发者的四个真实约束

聊技术选型之前，先把约束摆清楚。一个人做产品，你面对的不是"哪个框架最先进"的问题，是"哪套组合能让我活下来"的问题。

时间。一个新功能必须一天内跑通，不行就是两天，两天还搞不定就要砍需求。一人公司没有人陪你一起 debug，也没人帮你写 CI/CD。

成本。起步阶段必须能用免费额度跑，能把付费时间点拖到第一个真实用户付钱之后。每月固定 99 美元的基础开销在海外是小钱，在国内对独立开发者就是劝退信号。

合规。备案、支付、发票、实名认证——这些事情一个人全要扛。海外开发者收 Stripe 的钱走 Payoneer 回国内，这条路对大部分人来说太复杂，不如一开始就走微信支付。

生态。你的用户在哪里，决定了你的流量起点在哪里。国内产品最顺的冷启动是微信生态（小程序、公众号、视频号），海外产品最顺的是 Twitter + Product Hunt + Reddit。这两条路几乎不交叉。

海外标准栈（Next.js + Supabase + Vercel + Stripe）能成为标准，是因为它精准匹配了"海外一人公司"的四个约束。但国内的约束不同，最优解也必然不同——这不是技术问题，是地理和政策问题。

二、海外标准栈在国内踩过的坑

先说 Vercel。

Vercel 的边缘节点在海外，国内用户访问走跨境链路，我实测延迟 300-800ms 波动，高峰期掉包。这不是"配置优化能解决"的事，是物理距离决定的。你可以套一层 Cloudflare 加速，但 Cloudflare 在国内的状态你懂的——有时候能用，有时候连 DNS 都过不去。

然后是 Supabase。

Supabase 没有国内节点，数据库和 API 全在海外。即使你的前端部署在国内，后端调用依然要跨境。Pro 版本也改变不了这个物理现实。有人试过在国内搭 Supabase 自托管（它是开源的），但那就失去了选 Supabase 的初衷——你要的是"不用运维"，自托管等于把运维搬回来了。

最后是 Stripe。

这是最硬的坎。Stripe 不支持国内个人开发者注册，即使你注册了香港公司走 Stripe HK，收到的款要回大陆还得过一道汇款合规。对一个人的项目来说，这是无底洞。国内合规的支付路径只有微信支付、支付宝、银行聚合这几条，其中微信支付对小程序场景最顺，支付宝对 H5/PC 场景最顺。

这三样叠起来，海外标准栈在国内的实际体验是：前端慢、后端更慢、想收钱收不了。

有人会说，那就混合部署——前端走国内、后端还用 Supabase、支付走微信。可以，80aj.com 那篇混合架构文章就是这个思路，但它代价是你要同时维护两套部署、两套域名、两套监控。对一人公司来说，复杂度立刻翻倍。

三、我用 CloudBase 替换后的真实体感

CloudBase 能不能用？逐层看我踩了什么。

前端部署：Next.js 在 CloudBase 的真实支持度

这里很多人有个误解——以为 CloudBase 只能部署静态站点，Next.js 的 SSR/ISR 跑不了。实际上 CloudBase 提供了两种部署路径：HTTP 云函数和云托管（CloudRun），官方文档都有（docs.cloudbase.net/cloud-function/frameworks-examples/next、docs.cloudbase.net/run/develop/languages-frameworks/next）。

能力支持情况说明
SSG（静态生成）✅ 原生支持纯静态产物直接丢静态托管
SSR（服务端渲染）✅ 支持HTTP 云函数或云托管承载 next start
ISR（增量静态再生）✅ 支持同上，需要服务端进程常驻，云托管模式更稳
API Routes✅ 支持Node.js 进程直接处理
Middleware✅ 支持Node.js 兼容模式运行

实现路径是用 HTTP 云函数或云托管承载 next start，通过 scf_bootstrap 拉起 Node 服务监听 9000 端口。你需要改两个地方：

// next.config.js
const nextConfig = {
  output: 'standalone',
  images: { unoptimized: true },
};

加一个启动脚本 scf_bootstrap：

#!/bin/sh
export PORT=9000
export NODE_ENV=production
npm start

部署一次就跑起来了。

要承认的缺点：

  • next/image 的图片优化得禁掉，没有 Vercel 那种开箱即用的 Image Optimization
  • 云函数有冷启动，首次访问 1-3 秒，不如 Vercel 的边缘节点快
  • Windows 用户创建 scf_bootstrap 会遇到换行符问题（^M），要用 nano 或 vim
  • git push 即部署这个心智，CloudBase 要配合 CLI V3 才能做到，没 Vercel 那么傻瓜

所以结论是：技术完全可行，裸用的体验比 Vercel 差半级。

数据库：云数据库 vs Supabase PostgreSQL

Supabase 的数据库是 PostgreSQL，带 RLS（行级安全）、实时订阅、auto-generated REST 和 GraphQL API，这套组合目前还是业界最舒服的。

CloudBase 云数据库目前有三种选择：MongoDB 风格的文档型数据库、MySQL 关系型数据库，以及刚上线的 PostgreSQL 支持。差别很大：

  • 数据模型：Supabase 天然适合关系型思维，CloudBase 的文档型更适合小程序这种"一个文档对应一个业务对象"的结构；但如果你的模型就是强关系型，CloudBase 现在也能选 MySQL 或 PostgreSQL，不用非得迁就文档型
  • 权限模型：Supabase 的 RLS 是 SQL 语法，写起来严谨；CloudBase 的权限规则是 JSON，学习曲线短
  • 实时能力：Supabase 的 Realtime 基于 PostgreSQL logical replication，CloudBase 有实时数据库，功能对等但 API 不同
  • 客户端 SDK：Supabase 的 TypeScript 类型推导是杀手级体验，CloudBase 这边类型支持有，但不如 Supabase 强

如果你的数据模型是强关系型（电商、SaaS、财务），CloudBase 现在选 MySQL 或 PostgreSQL 也能接住，但 Supabase 的 RLS + 类型推导 + 实时订阅这套组合拳目前还是最顺的；如果是弱关系或文档型（内容平台、IoT、工具类小程序），CloudBase 的文档型更自然。

认证：CloudBase 身份认证 vs Supabase Auth

Supabase Auth 开箱即用支持 40 多种 OAuth provider，Google、GitHub、Apple、Twitter、Facebook 全都是一键配置。

CloudBase 身份认证的强项在国内生态——微信、QQ、手机号、邮箱是亲儿子，接入一行代码；海外 OAuth（Google、GitHub 等）需要自己通过 OAuth 2.0 标准流程接入，不是开箱即用。

结论：你的用户在哪里，决定了谁更好用。国内产品选 CloudBase，海外产品选 Supabase，这个没争议。

API / 后端：HTTP 云函数 vs Vercel Serverless

两者都是 Serverless Functions，冷启动和计费模式差不多。几个真实差异：

  • 部署单位：Vercel 是自动把 app/api/* 打包成 functions；CloudBase 需要显式声明或通过 Next.js 整体部署
  • 本地开发：Vercel 的 vercel dev 和生产环境一致度高；CloudBase 的本地调试要配合 CLI
  • 边缘计算：Vercel 有 Edge Runtime，能在全球边缘执行；CloudBase 云函数国内区域为主，新加坡节点已上线

支付：微信支付集成 vs Stripe

这一层没得选——你的用户在国内，就只能走微信/支付宝。

CloudBase 对微信支付的集成是官方方案，几行云函数就能打通下单、回调、退款。Stripe 那套 Checkout Session 的优雅 API 国内没有对等物，但你也用不上。

四、CloudBase 的边界，我老实讲

承认几件事。

社区生态不如 Supabase 成熟。Supabase 在 GitHub 有 70k+ Stars，Stack Overflow 上的问答量级是 CloudBase 的十倍以上。你遇到问题 Google，Supabase 大概率已经有人踩过；CloudBase 这边很多问题还要去官方社区或工单。

文档密度不够高。CloudBase 文档的基础 API 覆盖很全，但"完整项目示例"和"踩坑总结"类的内容明显偏少。新手从零开始，跟着 Supabase 官方 tutorial 一路能通关，跟着 CloudBase 文档走要自己补很多上下文。

海外场景反转没那么绝对。CloudBase 有新加坡节点，东南亚用户的延迟可以接受，但如果你的用户主要在欧美，那 Supabase + Vercel 仍然更顺。

纯手动部署的体验差距客观存在。Vercel 的 "connect your repo, we handle the rest" 是黄金标准——git push 就上线，你不需要知道什么 scf_bootstrap、端口 9000、standalone 输出。CloudBase 裸用确实要自己搞这些。

但这里有个转折——如果你在 AI 编辑器里配了 CloudBase 的 MCP（配置指南）和 Skills，很多配置细节不用自己碰。我部署云函数基本就是在对话里说一句"部署"，它自己打包上传；查数据库结构也不用去控制台翻，直接问。所以准确的说法是：裸用的体验比 Vercel 差，但配上 MCP/Skills 之后，差距缩小了不少。

把这些摆出来不是为了劝退，是让你心里有数——如果这些点你都能接受，后面再往下读就不会踩坑。

五、自建服务 vs 托管平台：一个人该把时间花在哪

聊到这儿，肯定有人想：我不选 CloudBase，也不选 Supabase，自己搭一套后端跑不就完了？

这条路径完全可行——我自己也用过。这里不比优劣，只说我从自建迁到托管平台之后，哪些事情不再需要我自己操心了。

SSL、日志、备份这些"持续运维"。自己搭服务的时候，SSL 证书续签、日志轮转、磁盘告警、安全补丁、数据库备份——每件事单独看都不难，但叠在一起就是持续的认知负担。迁到 CloudBase 之后这些全托管了，我不用再惦记。

MCP 集成。我在 AI 编辑器里配了 CloudBase MCP 之后，查数据库结构、部署云函数、配权限规则都是一句对话的事。自建服务做同样的事，目前还没有这种原生集成——不是做不到，是你得自己搭工具链。

环境一致性。自建的好处是灵活——想装什么装什么，想怎么配怎么配。CloudBase 托管的好处是不用配——运行环境、端口、启动脚本都是约定好的，不给你出错的机会。两种思路，适合不同阶段：你想精细控制的时候自建更合适，你想少操心的时候托管更省事。

所以我的体感是：自建给灵活性，托管平台省注意力。一人公司的核心约束是时间，选哪个取决于你当前更缺哪个。

六、分场景的选型建议

不同场景，不同答案。

场景推荐技术栈关键理由
纯国内 B/C 端产品（小程序、公众号、国内 SaaS）CloudBase 一套平台收敛延迟、合规、支付三件事一个控制台搞定
出海产品（欧美用户为主）Next.js + Supabase + Vercel + Stripe海外节点、OAuth 全家桶、Stripe 合规
出海产品（东南亚用户）CloudBase 新加坡节点低延迟 + 国内合规，省掉双栈复杂度
混合场景（国内外都有用户）CloudBase 国内 + Supabase 海外（或反过来）平衡延迟和合规，但复杂度翻倍
已有 Vercel 项目想补国内体验前端部署到 CloudBase 静态托管 + 云函数做 API 层，Supabase 继续用但加缓存最小改动，先解决前端延迟
需要精细控制运行环境自建服务灵活度高，但运维认知负担也高

再具体一点——

纯国内场景下，如果你在做一个小程序 + H5 的双端产品，CloudBase 一套跑完：

  • 前端（小程序原生 + Next.js H5）都托管在 CloudBase
  • 数据库按需选：文档型（小程序场景最顺）、MySQL 或 PostgreSQL（强关系型场景）
  • 用户登录用微信一键授权
  • 支付用微信支付（官方方案，几行云函数打通）
  • AI 能力走 CloudBase AI Toolkit（如果要用）

整个栈你只有一份账单，一个控制台。对一人公司的认知负担友好，这比什么都重要。

出海场景下，看用户在哪里。东南亚用户，CloudBase 新加坡节点能接住，省得再搭一套。欧美用户为主，那 Supabase + Vercel + Stripe 仍然是最优解。

混合场景下是最复杂的。我的建议是——先判断你 80% 用户在哪里，按主流场景选栈，另一边做降级体验。如果真做到 50:50，那就接受双轨部署的复杂度，别指望一套栈能全搞定。

七、2026 年最大的变量——AI 辅助开发

前面几章聊的都是传统维度的比较——延迟、成本、合规、生态。但 2026 年有个新维度正在变成实际考量：AI 写你这套栈，能写对吗？

这不是噱头。我现在写代码基本离不开 AI 编辑器，一个人做产品的效率能不能撑住，很大程度上取决于 AI 能帮你多少。而 AI 能帮你多少，取决于你选的栈 AI 有多"认识"它。

AI 认识谁，不认识谁

Next.js 是 LLM 训练数据里最常见的框架之一，AI 写 Next.js 代码的正确率远高于冷门框架。Supabase 也类似——GitHub 70k Stars 意味着海量的教程、问答、示例代码进了训练集，AI 对 Supabase 的 API 几乎不会编造。

CloudBase 在这个维度上确实吃亏。训练数据少，AI 偶尔会编一些不存在的 API，比如把云函数的入口参数搞混，或者编一个根本不存在的 SDK 方法。这种"看似正确实则跑不通"的代码，比完全不会还烦——你得 debug 半天才发现是 AI 编的。

MCP：让 AI 编辑器直接操作后端

但 CloudBase 有个东西帮它补了很多——MCP（配置指南）。

MCP 的意思是 Model Context Protocol，说人话就是：让 AI 编辑器能直接操作你的后端平台。我习惯在 Cursor 里用 CloudBase MCP 直接操作数据库和云函数，省得在编辑器和控制台之间切来切去。具体能干什么：

  • 查数据库结构："我的 users 集合有哪些字段？"直接问，不用去控制台翻
  • 部署云函数："把 login 函数部署上去"，它自己打包上传
  • 配置权限规则："给 articles 集合加一个只读规则"，它直接写
  • 查日志："最近一次云函数报错是什么？"直接看

Supabase 也有 MCP，两边思路差不多。我的体感是 CloudBase 这边因为 MCP 是官方主推的方向，迭代比较快，我日常用着挺顺。

Skills：让 AI 理解架构规则

CloudBase 还有个 Skills 的概念（使用指南），比 MCP 更进一步——不只是操作，是让 AI 编辑器自动理解 CloudBase 的架构规则和最佳实践。

什么意思呢？没有 Skills 的时候，AI 可能给你生成一段云函数代码，但权限规则配得不对，或者数据库操作没走索引。有了 Skills，AI 生成的代码会自动遵循 CloudBase 的约定——安全规则格式对了，云函数入口参数对了，SDK 调用方式对了。

我的体感是——装了 Skills 之后，AI 生成的 CloudBase 代码出错率明显低了一些。不是万能的，但比裸写好。

但别过度神化

说完了好的，也得说边界。

AI 辅助只是加分项，不是翻盘因素。如果你的核心约束是"用户在国内但你的后端在海外"，那 AI 再怎么帮你写代码，延迟问题还是解决不了。核心约束依然是前面那四条——时间、成本、合规、生态。

另外 MCP 和 Skills 目前也有限制——复杂的多表关联查询，AI 还是容易写错；云函数的冷启动优化，AI 也帮不了你。它们解决的是"重复性操作"和"约定遵循"的问题，不是架构设计的问题。

写在最后

一人公司不是"把大公司那套缩小"，是另一种约束下的另一种最优解。

海外一人公司用 Next.js + Supabase + Vercel + Stripe，因为这套匹配他们的约束。国内一人公司不应该原样照搬——不是国内工具不行，是约束不同。

CloudBase 不是完美替代，但在国内场景下它把延迟、合规、支付这三件最硬的事一次性收敛了。代价是你要接受：社区不如 Supabase 热闹、文档不如 Vercel 保姆、DX 比 git push 差一截。

值不值得换？看你自己算账——

  • 如果你的用户明天就要能付钱，而你不想花两周接 Stripe 出海，CloudBase 在国内至少能让你先把钱收了
  • 如果你的用户在东南亚，CloudBase 新加坡节点够用，不用再搭一套海外栈
  • 如果你的用户在欧美，Supabase + Vercel 仍然更顺
  • 如果你两边都要，接受复杂度，搭混合架构
  • 如果你需要精细控制运行环境——自建服务更灵活，但运维精力你自己掂量

这篇不替你做决定，只是把各层的坑和边界摆清楚。剩下的你自己判断。

参考资料

avatar
文章
阅读
粉丝