在 Vercel 上规划后端架构时，按工作负载选择…

当需要规划、构建或迁移 API/后端，并在 Vercel 的多种后端产品与框架之间做选择时，按工作负载而非编程语言来匹配架构。

适用场景

解决思路

1. 先识别工作负载中的四类要素：同步请求、异步工作、持久化数据、可独立部署的组件，再据此选产品，最后选框架。
2. HTTP API、webhook、流式响应或框架服务端代码：使用 Vercel Functions 配合 Fluid compute。
3. 双向实时连接（WebSocket）：使用 Vercel Functions with Fluid compute，无需单独部署实时服务。
4. 前端与一个或多个后端（API 端点）需要一起部署：使用 Vercel Services。
5. 已有 Dockerfile、需要自定义运行时或系统依赖：在 Vercel Functions 上使用 Container images，并可选地与 Services 组合。
6. 需要带重试、休眠或外部事件的多步骤持久化工作：使用 Vercel Workflow。
7. 后台任务、缓冲、扇出或直接消息路由：使用 Vercel Queues。
8. 定时 HTTP 任务：使用 Vercel Cron Jobs；若任务本身需要持久化，则改用 Workflow。
9. Postgres、Redis、NoSQL、向量或其他应用数据：通过 Vercel Marketplace 的 Storage integrations 提供。
10. 文件与用户上传：使用 Vercel Blob。
11. 全局、读多写少的配置：使用 Global Config。
12. 常规请求/响应后端用 Functions；当多个独立构建的组件需要共享一次部署、路由层、预览 URL 和回滚时用 Services；当组件需要独立发布周期时用独立的 Vercel 项目。
13. 对受支持的框架优先使用原生 Functions 运行时；仅当已有 Dockerfile 或需要自定义运行时/系统依赖时才用容器镜像，它们以自动扩缩、无状态的 Functions 方式运行，而不是常驻容器主机。
14. 后台任务、缓冲、扇出和消息路由选 Queues；持久化多步骤业务逻辑选 Workflow。
15. 通过 Marketplace 提供数据存储，使凭据自动注入项目并保持各环境连通；选择供应商前先查看当前目录。
16. 可选的数据库供应商：Postgres 用 Neon、Supabase、AWS/Aurora、Nile、Prisma；MySQL 用 AWS/Aurora；Redis 与键值用 Upstash、Redis；文档与 NoSQL 用 MongoDB Atlas、AWS；SQLite 用 Turso；实时应用后端用 Convex；分析用 MotherDuck。
17. 让数据库靠近 Functions 所在区域，并使用兼容 serverless 的连接或连接池。
18. 受一等支持的后端框架：Node.js/TypeScript 用 Elysia、Express、Fastify、H3、Hono、Koa、NestJS、Nitro、xmcp；当后端属于 Next.js 应用时，Next.js Route Handlers 是自然选择；Python 用 FastAPI、Flask、Django，其他 WSGI/ASGI 应用在导出兼容的 `app` 并可做额外配置时也可运行；Go 作为 Vercel Functions 运行时受支持。
19. 前后端组合（例如 Next.js/Vite/SvelteKit 前端配 FastAPI/Flask/Express/Go 后端）可用 Services 在同一项目中一起部署。
20. 优先沿用用户已有的框架；新项目则根据生态与应用需求选择。
21. 选定产品与框架后，加载对应的聚焦技能进行实现：`vercel-functions`、`vercel-services`、`workflow`、`vercel-storage` 或 `marketplace`。
22. 部署前在官方文档中确认函数限制、区域、环境变量、可观测性以及当前产品可用性。

适用边界 · 注意事项

• 该技能依赖 Vercel 平台及其 Functions、Services、Queues、Workflow、Marketplace 等产品，不适用于非 Vercel 部署环境。
• 当项目不需要 Vercel 托管后端、或已有其他云厂商的等价架构时，不必套用此产品映射。