作者：Nathan Nie，Codex
当我们说一个网站“部署在 Vercel 上”时，真正的意思往往不是“它用的是 Vercel 的域名”，而是“它把从代码到上线的那一整套流程交给了 Vercel”。
一个常见误解：有自己的域名，就不算部署在 Vercel 吗？
很多人第一次接触 Vercel，都会有一个很自然的疑问：
一个网站明明访问的是自己的域名，比如 jmail.world，为什么别人还会说它“部署在 Vercel 上”？既然它不是 xxx.vercel.app，那 Vercel 到底扮演的是什么角色？
这个疑问本身非常合理，因为我们平时很容易把三件不同的事情混在一起说：
- 域名
- 部署平台
- 底层服务器
如果不先把这三层拆开，Vercel 和 AWS、阿里云这类云厂商的区别就会一直显得有点模糊。
先把三个概念分开：域名、部署平台、底层算力
一个网站能被访问，通常至少涉及三层。
第一层是域名。
比如 example.com、jmail.world。它更像网站的门牌号，负责让用户找到你的站点。
第二层是部署平台。
比如 Vercel、Netlify、Render。它们负责把你的代码构建出来，发布出去，并处理 HTTPS、CDN、预览环境、环境变量、回滚等工程问题。
第三层是底层算力和网络资源。
这才是更接近传统“服务器”的那一层，例如 AWS、阿里云、Google Cloud 提供的虚拟机、容器、对象存储、函数计算和网络设施。
所以，一个网站“有自己的域名”和“部署在 Vercel 上”完全不冲突。
自定义域名只是入口。网站背后的构建、发布、证书、CDN 分发，甚至部分后端逻辑，依然可以是由 Vercel 负责。
Vercel 扮演的角色是什么？
如果只用一句话来概括，Vercel 不是传统意义上“卖服务器给你”的公司，而是一个把现代 Web 应用部署流程做成产品的平台。
它做的事情通常包括：
- 连接 GitHub 或 GitLab 仓库
- 在代码提交后自动构建项目
- 生成生产环境和预览环境
- 将静态资源分发到 CDN
- 运行函数式的后端逻辑
- 管理环境变量
- 绑定自定义域名并配置 HTTPS
- 在新版本出问题时快速回滚
也就是说，Vercel 的核心价值并不是“给你一台机器”，而是“把从代码到上线的整条链路都包装好”。
从开发者视角看，体验会非常不一样：你不再主要思考“这台机器怎么配”，而是更多思考“这份代码能不能顺利构建和运行”。
为什么用了自己的域名，看起来却不像在 Vercel 上？
原因很简单：域名和托管平台本来就不是一回事。
你完全可以：
- 在阿里云、Cloudflare 或 GoDaddy 买域名
- 把代码放在 GitHub
- 用 Vercel 做部署
- 把 DNS 记录指向 Vercel
这样一来，用户看到的是 www.example.com，而不是默认的 xxx.vercel.app。但这个网站的发布、证书、缓存和分发，仍然可能由 Vercel 处理。
所以，“有自己的域名”不能说明“不是部署在 Vercel”，它只说明网站没有直接暴露平台默认地址。
Vercel 和云服务器，到底差在哪？
这是最值得讲清楚的部分。
如果你买的是 AWS EC2、阿里云 ECS、腾讯云轻量服务器，本质上你拿到的是一台机器，或者一组由你自己管理的机器。接下来你通常要自己处理：
- 安装运行环境
- 配置 Nginx 或其他反向代理
- 启动 Node、Python、Java 等应用
- 管理进程守护
- 配置 SSL 证书
- 编写部署脚本
- 处理日志、监控、告警和备份
- 设计扩容和回滚流程
换句话说，在云服务器模式下，你的责任边界会更靠近操作系统和网络层。
而在 Vercel 上，你通常不需要直接管理这些东西。你主要负责：
- 提交代码
- 配好环境变量
- 保证应用能构建
- 保证接口逻辑符合平台运行方式
至于构建、发布、CDN、证书、预览环境、回滚等事情，平台已经替你处理了很大一部分。
所以更准确地说：
- 云服务器像是给你一套毛坯房
- Vercel 更像是一套装修好的公寓
前者自由度更高，后者省心程度更高。
为什么大家常说 Vercel 适合“轻后端”？
这里的“轻后端”，并不是说它不能做后端，而是说它更适合下面这类后端场景：
- 请求时间短
- 偏无状态
- 通过 HTTP 提供服务
- 不依赖常驻进程
- 不需要自己维护大量长连接
比如这些需求就很适合：
- 登录和鉴权
- 表单提交
- 查询数据库
- 提供少量 API
- 服务端渲染页面
- 调用第三方服务
- AI 流式响应
这些场景的共同点是：请求来了，执行一段逻辑，返回结果，然后这次处理就结束了。
Vercel 很擅长处理这样的工作负载，因为它的核心模型更偏向“按请求触发执行”，而不是“给你一台永远开着的机器，让你长期维持一组服务”。
什么样的项目不太适合 Vercel？
如果你的项目需要的是下面这些能力，那通常更适合自己控制服务器、容器平台或 Kubernetes：
- 大量 WebSocket 长连接
- 常驻 worker
- 持续运行的消息消费程序
- 视频转码、音频处理等重任务
- 深度依赖本地磁盘
- 很复杂的系统级网络控制
- 多服务之间的长期内部通信
这些需求本质上都更像是“我要长期经营一组服务”，而不是“我希望请求来了再执行一下代码”。
而 Vercel 的设计哲学恰恰是尽量把你从“运维机器”这件事里解放出来，所以它天然更偏向轻量、短时、面向 Web 请求的后端。
一个更容易理解的例子
假设你要做一个产品官网，包含：
- 首页
- 博客
- 文档页
- 联系我们表单
- 少量后台接口
这类项目往往非常适合 Vercel。
原因并不复杂：
- 页面多，更新频繁
- 前端体验要求高
- 需要预览环境给团队看效果
- 希望每次提交代码后自动上线
- 后端逻辑不重
你把代码放进 GitHub，连上 Vercel，每次 git push 后平台自动构建、发布、配 HTTPS、生成预览链接，并把最终网站绑定到你自己的域名上。对于大多数中小型内容站、官网和前后端一体应用来说，这样的体验是非常顺滑的。
再看另一个例子：如果你做的是在线客服系统，要求支持实时聊天、坐席状态同步、消息推送、消息队列、后台任务和日志消费，那事情就变了。
这类系统通常更适合：
- 云服务器
- Docker
- Kubernetes
- 或者其他更可控的后端基础设施
因为它们需要的是常驻服务、长连接和更高的系统控制权，而不是只把代码“部署出去”那么简单。
Vercel 托管代码，和自己在云服务器上托管，本质区别是什么？
最本质的一句话其实是：
在自己的云服务器上，你是在运维机器；在 Vercel 上，你是在交付部署结果。
这句话背后意味着两种完全不同的工作方式。
在 Vercel 上：
- 你主要关注代码和构建
- 平台负责大量部署细节
- 你获得更快的上线速度和更低的运维成本
在自己的云服务器上：
- 你不仅要关注代码
- 还要负责系统、网络、进程、安全、监控和扩容
- 你获得更高的自由度，也承担更高的复杂度
所以这两种方式的区别，并不只是“部署命令不同”，而是你到底想不想自己管理机器，以及你的项目是否真的需要你去管理那一层。
一张表看懂：Vercel vs 自己的云服务器
| 维度 | Vercel | 自己的云服务器 |
|---|---|---|
| 你拿到的东西 | 部署平台 | 一台机器或一组机器 |
| 上线方式 | 连 Git 自动构建发布 | 自己写部署脚本和流程 |
| HTTPS | 平台自动处理 | 自己申请和续期 |
| CDN | 平台通常内置 | 需要自己接入 |
| 预览环境 | 天然支持 | 通常要自己搭 |
| 回滚 | 很方便 | 需要自己设计 |
| 运维成本 | 低 | 高 |
| 自由度 | 中等 | 很高 |
| 适合项目 | 官网、博客、文档站、轻 API | 长连接、重后端、常驻服务、复杂系统 |
| 典型心智模型 | 交代码给平台运行 | 自己经营服务器 |
什么时候该选 Vercel，什么时候该选云服务器？
如果你的项目更像下面这些关键词：
- 官网
- 博客
- 文档站
- Next.js 应用
- 中小型前后端一体项目
- SSR 页面
- 轻量 API
那 Vercel 往往是非常舒服的选择。
如果你的项目更像下面这些关键词：
- 即时通讯
- 长连接
- 常驻服务
- 队列系统
- 音视频处理
- 重任务处理
- 微服务集群
那云服务器、容器平台或者 Kubernetes 通常会更合适。
结语
很多人第一次看到一个网站用了自己的域名，就会下意识地认为它一定是“自己买服务器部署的”。其实不是。
域名只是门牌号，Vercel 是部署平台，而底层服务器又是另一层基础设施。把这三层分开之后，Vercel 和传统云服务器的区别就清楚了：
Vercel 不是为了替代所有服务器而存在的，它更像是把现代 Web 应用最常见、最繁琐的上线流程做成了一种省心的默认方案。
如果你的项目主要是页面、内容、轻接口和快速迭代，Vercel 往往会非常顺手；如果你的项目是重后端、强状态、长连接和常驻任务，那你更需要的，通常还是对服务器本身的掌控权。
理解了这一点，再看类似 jmail.world 这样的站点，就不容易困惑了：用户看到的是它自己的域名，而真正帮它把代码稳定发布到线上、处理证书和分发的，完全可能是 Vercel。