vercel是什么

你可能在教程里见过「推上去就自动部署」，也见过别人说「Vercel 只适合前端」。真要动手时反而卡在几个问题上：它到底替我做了什么、哪些东西它不做、免费额度撑到哪一步、什么时候该换别家。这篇按「它解决的问题 → 核心能力 → 边界 → 选型判断」的顺序讲一遍，读完能自己决定要不要把项目放上去。

你可能在教程里见过「推上去就自动部署」，也见过别人说「Vercel 只适合前端」。真要动手时反而卡在几个问题上：它到底替我做了什么、哪些东西它不做、免费额度撑到哪一步、什么时候该换别家。这篇按「它解决的问题 → 核心能力 → 边界 → 选型判断」的顺序讲一遍，读完能自己决定要不要把项目放上去。

先给结论：Vercel 是一个和 Git 仓库绑定的前端托管平台，外加一层构建流水线和边缘分发。你交出去的是「部署这件事」，换来的是省事和一致性；代价是自由度，以及某些场景下它和你的预期不一致。下面拆开讲。

一句话定位：它到底是个什么东西

把它理解成「和 Git 仓库绑定的前端托管 + 构建流水线」，而不是一台给你 root 权限的服务器。你不需要登机器装环境、配 Nginx、写发布脚本；你只需要把仓库连上去，它按约定拉代码、跑构建、把产物推到节点上。这个模型决定了它能做的事情有明确边界。

它主要替你干三件事：拉代码构建、把产物分发到全球节点、给每次提交生成一个可访问的预览地址。这三件事原来都是要手工做的，现在变成默认行为。判断自己适不适合，就看你的项目是不是「构建一次、之后基本只读」的形态。

• 构建：连上仓库就自动识别框架，推分支触发一次流水线，产物和提交一一对应
• 分发：静态资源走节点缓存，用户就近取，重点看首屏和二次访问的差别
• 预览：每个分支或合并请求一个独立地址，评审不用等主站合并
• 差异化：和传统虚拟主机、云服务器的分工差别在于，你放弃的是机器控制权，换到的是部署的确定性和一致性

核心功能拆开看：构建、预览、分发、函数

构建这一层最关键的是「可复现」。同一次提交在本地和在平台上跑出来的结果应该一致，所以你要先把构建命令和输出目录写清楚，别全指望自动识别。识别错了，后面排错会绕很远。

预览环境是很多人留下来不走的真正理由。每个分支一个独立地址，产品或设计直接在真机上点，发现问题在对应分支改，主分支始终是可发布状态。这套流程的价值随团队人数上升，一个人做小项目时感受不明显。

Serverless 和 Edge 函数要单独说：它适合轻量接口、鉴权、转发、重写，不适合长任务。它按请求和运行时计费，和常驻服务不是一回事。你要把它当成「项目里的一小段逻辑」，而不是一台后端服务器。

从零到上线的可执行步骤

下面这套顺序，一个人做和五个人做都适用。核心原则是：先在本地确认能干净地跑一次生产构建，再谈连平台。本地都跑不通，平台上的报错只会更难读。

1. 确认本地生产构建在本地跑一次完整的生产构建命令，记录构建命令、输出目录、Node 版本。这一步过不了就别往下走。
2. 导入仓库并逐项核对连上仓库后，不要只点确认。逐个核对框架预设、构建命令、输出目录、环境变量四项，和本地记录对一遍。
3. 先发预览地址验证用真机和不登录的浏览器各走一遍主流程：首页、关键跳转、接口调用、错误页。确认无误再合并到主分支。
4. 绑定域名并分环境配变量绑定自己的域名后确认证书状态。线上域名和预览域名的环境变量分开配，避免预览环境写进生产数据。

第四步容易被忽略。很多「预览能用、线上挂了」的问题，根因就是环境变量只有一份。把两套配置分开写进仓库文档，换人或换平台时都能省一轮排查。

免费额度与付费档位：先看口径再看数字

免费档通常对个人项目、非商用场景够用，但真正会绊倒你的往往不是大额度，而是并发、构建时长、函数执行时长这些软限制。它们平时不显眼，一到上线当天就集中爆发。判断自己的项目会不会撞线，先看有没有「同时很多人访问」和「单次请求跑很久」这两种特征。

付费的分界线通常是协作能力，而不是流量。判断标准很朴素：有没有第二个人要登录看部署、要不要访问控制、要不要保留更久的日志。这三条只要中一条，基本就在付费档区间了。具体的档位名称、额度数值、区域差价会变，去站内的 /plans 和 /official-api 核对你下单那天的口径，别用别人半年前的文章做决策。

• 先区分硬限制和软限制：磁盘、项目数通常是硬的，并发、时长通常是软的且更容易撞
• 把用量盯一到两周：个人项目跑起来后再决定升不升级，比提前买更准
• 函数调用量和带宽是账单主要变量，上线前先估量级而不是估次数
• 区域差价和计费单位会变，任何数字都以站内当天的页面为准

什么情况下别选它：几条反向判断

先说最容易踩的一条：需要长时间运行的进程、定时跑很久的任务、要连内网数据库的项目，用无服务器模型会很别扭。不是做不了，是要绕着做，长期维护成本高。如果你的核心逻辑就是「一个常驻进程 + 一个内网库」，那它从第一天起就不合适。

第二条是数据和合规。数据必须落在特定地域、或有明确存放要求时，先确认节点范围能不能满足，再谈部署体验。这类约束通常不是技术问题，而是流程问题，事后补很贵。

• 需要常驻后台进程或超长任务：默认模型不支持，硬做要额外绕一层
• 数据有明确地域或合规要求：先确认节点范围，别先部署后补材料
• 团队已有成熟容器与发布流程：再叠一个平台只会让排查链路变长
• 极低预算加极小流量的静态站：别家静态托管也能做，选它的理由应该是省事不是省钱

和常见替代路线怎么比：几个判断维度

比「谁更省事」：托管平台胜在零运维，云服务器胜在自由度。选的依据不是哪个更先进，而是你的团队有没有运维人力。一个人或小团队，把时间花在业务上更划算；有专职运维且流程成熟，自建反而更可控。

比「冷启动与延迟」：这类表现和你的代码、区域、访问来源强相关，别人的结论对你未必成立。做法是自己建一条基线：上线前用真机在几个主要地区量一次首屏和接口响应，记下来，之后再改。站内的 /tools/speed-test 可以帮你把这条基线固定下来。

比「可迁移性」：部署配置越贴近标准框架，将来换平台越便宜。把构建命令、环境变量、需要的运行时版本都写进仓库文档里，别只留在平台后台。这份文档是你以后换家的底气。

比「成本结构」：固定月费、按量、按人头三种模式的账单曲线不一样。低流量时按量看着便宜，流量涨起来后固定月费可能更稳。不用精确到分，先估一个量级就够了，站内 /tools/model-cost-calculator 这类工具可以先帮你把量级摸出来。

最后提醒一句：无论选哪条路，先把自己项目的形态说清楚——是纯静态、有轻接口，还是需要常驻服务。形态定了，选项其实不多，剩下的只是去核对当天的数字。