部署上线：Vercel / Netlify / Cloudflare / 自有服务器怎么选、怎么发

你的 MVP 在本地 npm run dev 跑得好好的，截图发群里大家都说不错。然后有人问："链接发我一下？"——你卡住了。它只活在你这台电脑的 localhost:3000 上，关掉终端就没了。把一个只有你能看到的项目，变成全世界输入网址就能打开的网站，这一步叫"部署"。 这一节就带你把这步走通。

这篇适合谁：你已经能用 AI 做出一个能跑的前端站或小应用，但从没正经部署过，一听到"服务器""构建""环境变量"就发怵。读完你会亲手把一个项目发上线，并且知道下次换个项目该怎么选托管。

---

先分清：你要部署的是"静态站"还是"全栈应用"

选托管之前，先搞清楚你手里这个东西是哪一类，这决定了一半的选择。

静态站 / 纯前端：构建之后产出的是一堆 HTML、CSS、JS 文件，浏览器直接加载就能跑，没有"服务器在后台一直运行着算东西"。你用 React、Vue、Astro、或者纯 HTML 做的展示站、落地页、博客、文档站，绝大多数都属于这类。哪怕它有交互、有动画，只要数据不需要后端实时算，它就是静态的。

全栈应用：除了前端页面，还有一段代码要在服务器上运行——比如用户登录要查数据库、表单提交要存数据、要调用第三方 API 又不能暴露密钥。这类应用有"后端"，需要一个能持续运行后端代码的地方。

判断口诀：如果你的项目里没有任何"必须藏在服务器才能跑"的代码，它就是静态站，部署起来最省事。 一旦有了数据库、登录、付费这些，就是全栈，要么靠平台的 Serverless 函数，要么得有真服务器。

为什么先分这个？因为静态站几乎所有平台都能一键免费发，而全栈应用要考虑后端怎么跑、数据放哪——后者属于下一节数据库与后端的话题，这一节先把"页面发上线"这件事吃透。

---

四种托管，分别适合谁

Vercel / Netlify / Cloudflare Pages：前端友好型

这三家是一类东西：面向前端开发者的"连仓库就自动部署"平台，你不用碰服务器，推代码它就帮你构建、发布、配好 HTTPS。它们都有免费额度，个人项目和 MVP 基本够用。

• Vercel：对 Next.js 这类前端框架支持最丝滑（Next.js 就是 Vercel 家做的）。自带 Serverless 函数，前端带一点轻后端逻辑也能扛。新手最顺手的一个。
• Netlify：老牌选手，对各种静态站框架都友好，表单收集、重定向规则这些配置做得很细。文档清楚，适合做内容站、落地页。
• Cloudflare Pages：背靠 Cloudflare 的全球 CDN，访问速度有优势，免费额度给得大方。它的边缘函数（Workers）生态强，适合想顺带玩点边缘计算的人。

它们的共性优点：零运维、自动 HTTPS、推代码就自动重新部署、免费额度够个人用。共性的坑：免费额度有上限（构建分钟数、流量、函数调用次数），项目做大了可能要付费；重后端、长时间运行的任务它们不擅长（Serverless 函数有执行时长限制）。

自有服务器（VPS）：可控但要自己运维

VPS（Virtual Private Server，虚拟专用服务器）就是云厂商租给你的一台 Linux 机器，你有完整的控制权——想装什么装什么，想跑什么跑什么。阿里云、腾讯云、AWS、DigitalOcean 都卖这个。

适合谁：你需要长时间运行的后端、要装特定的数据库或服务、要完全掌控环境、或者国内业务要备案落地到自己的服务器。代价：所有运维都得你自己来——配 Nginx、装环境、开 HTTPS、做安全更新、出了问题自己排查。对一个还在验证想法的 MVP 来说，这通常是过度投入。

一句话选型：只是发个前端站/落地页/MVP → 选 Vercel/Netlify/Cloudflare Pages，别碰服务器。 真有持续运行的后端、或国内备案落地需求，再考虑 VPS。

---

这篇的增量一：托管平台选型表

平台	最适合	免费额度量级（以官方为准）	主要的坑
Vercel	Next.js / 前端框架 + 轻量后端函数	个人免费，有构建时长和函数调用上限	商业项目流量大了要升级付费；函数执行有时长限制
Netlify	静态内容站、落地页、文档站	个人免费，有构建分钟和带宽上限	构建分钟数容易在频繁部署时耗光
Cloudflare Pages	静态站 + 想用边缘函数、看重访问速度	免费额度给得大，构建次数有上限	边缘函数有自己的写法和限制，学习成本
自有服务器 VPS	持续运行的后端、要完全控制环境、国内备案落地	按月付费，无"免费"一说	全部运维自己扛，是时间黑洞

注：各平台的具体额度数字经常调整，以官方文档为准，别照着某篇旧文里的数字下结论。

---

走一遍最小部署流程：连仓库就自动上线

下面以"前端友好型平台 + 一个 git 仓库"为例，走通完整流程。三家平台操作大同小异，这里讲通用步骤，具体按钮文案以官方为准。

第一步：把代码推到 git 仓库

平台是通过读你的 git 仓库来构建的，所以先得有仓库。把你的项目推到 GitHub（GitLab、Gitee 也行，看平台支持）：

# 在你的项目根目录
git init
git add .
git commit -m "first deploy"
# 在 GitHub 网页上建好空仓库后，拿到地址，关联并推上去
git remote add origin https://github.com/你的用户名/你的项目.git
git push -u origin main

你应该看到什么：终端显示推送成功，刷新 GitHub 仓库页面，能看到你的全部代码文件。这一步成了，平台才有东西可读。

第二步：在平台上"导入"这个仓库

登录托管平台，找到"New Project / Import / 新建"入口，授权它访问你的 GitHub，从列表里选中刚才那个仓库。

你应该看到什么：平台会自动识别你用的框架（比如认出这是 Next.js / Vite / Astro 项目），并预填好构建命令和输出目录。多数情况它猜得对，你只需确认。

第三步：确认构建配置

这里有两个关键字段，理解它们能帮你躲掉最常见的部署失败：

• 构建命令（Build Command）：平台执行这条命令来打包你的项目，通常是 npm run build。它对应你 package.json 里 scripts 中的 build。
• 输出目录（Output / Publish Directory）：构建完成后，那堆要发布的静态文件放在哪个文件夹。常见值是 dist、build、.next 或 out——具体看你的框架。如果平台自动识别了框架，这个一般不用动。

判断方法：你在本地敲 npm run build 后，生成文件在哪个文件夹，这里就填哪个。

第四步：配环境变量（如果有）

如果你的项目用到了 API 密钥、第三方服务地址这类敏感或环境相关的值，绝不能硬编码在代码里推到仓库（推上去就等于公开了）。正确做法是在平台的 "Environment Variables / 环境变量" 设置里一条条加进去。

比如你代码里读 process.env.NEXT_PUBLIC_API_URL，就在平台加一条 key 为 NEXT_PUBLIC_API_URL、value 为实际地址的变量。

注意：前端能读到的环境变量通常需要特定前缀（如 Next.js 的 NEXT_PUBLIC_、Vite 的 VITE_），否则它只在构建时存在、浏览器里读不到。具体前缀规则以你的框架官方文档为准。

第五步：点击部署，看构建日志

点 "Deploy"。平台会拉取代码、安装依赖、跑构建命令、把产物发布出去。

你应该看到什么：一个实时滚动的构建日志，依次出现类似 Installing dependencies、Running build command、Build completed、最后是 Deployment ready 加一个 *.vercel.app / *.netlify.app / *.pages.dev 的网址。点开这个网址，你的站就在公网上了。

这一刻的意义：刚才还只活在你 localhost 上的项目，现在地球上任何人输入这个网址都能打开。从这步往后，每次你 git push，平台会自动重新构建、更新线上版本——这就是"持续部署"，你以后改东西只管推代码。

---

故障排查：上线卡住时照这张表查

第一次部署十有八九会红一次，别慌，照现象对号入座。

现象	最可能的原因	怎么办
构建日志报红、Build failed	本地没跑过 npm run build，代码本身构建不过	先在本地 npm run build 跑通，本地都过不了平台一定过不了；把报错复制回喂给 AI
构建里报 Module not found / 缺包	依赖没写进 package.json，只在你本地装了	确认 package.json 的 dependencies 完整，且 package-lock.json 一起提交了
页面打开是空白 / 404	输出目录填错，平台发布了错误的文件夹	核对输出目录＝本地构建产物所在文件夹（dist/build/out 等）
功能正常但调接口全失败	环境变量没在平台配，或前缀不对	在平台环境变量里补齐；前端变量确认带了框架要求的前缀，配完要重新部署一次才生效
多页应用刷新子页面就 404	单页应用（SPA）路由没配重定向回退	加一条"所有路径回退到 index.html"的重定向规则（各平台叫法不同，以官方为准）
本地好好的，线上样式/图片丢了	资源路径写死成绝对路径或本地路径	用相对路径或框架推荐的静态资源引用方式

这里最值钱的一条是第一行：部署失败八成不是平台的问题，是你的项目本地就构建不过。 上线前先在本地 npm run build 跑一遍，能省掉一大半折腾。

---

变体：如果你非要用自有服务器，Nginx 思路是什么

哪天你真有了持续运行的后端、或要把站落到自己的 VPS 上（比如国内备案需要），整体思路是这样的——这里只讲机制，不背具体命令：

1. 租一台 VPS，拿到一个公网 IP 和登录方式（SSH）。
2. 在服务器上装好运行环境：前端站就把构建好的静态文件传上去；有后端就装 Node/Python 等，把后端进程跑起来（一般用 PM2、systemd 之类的工具守护着，防止它崩了不重启）。
3. 装 Nginx 当"门口的接待员"：Nginx 是一个反向代理 + 静态文件服务器。它负责接住所有访问你域名的请求，静态文件直接吐给浏览器，需要后端的请求转发给你后台跑着的进程。
4. 把域名解析到这台服务器的 IP，配上 HTTPS 证书——这部分属于下一节域名 / HTTPS / DNS 的内容。

核心区别一句话：前端平台是"你推代码，它全自动"；自有服务器是"每一环都你手动搭、手动维护"。 自由度换来的是运维负担，所以 MVP 阶段能不上服务器就不上。

---

增量二：首次部署 checklist

发布前对着过一遍，能躲掉绝大多数翻车：

• 本地 npm run build 能跑通，无报错
• 代码已推到 git 仓库，敏感密钥没有硬编码在代码里
• .gitignore 里排除了 node_modules、.env 等不该上传的东西
• 构建命令和输出目录确认无误（＝本地构建产物所在文件夹）
• 所有用到的环境变量都在平台配好，前端变量带了正确前缀
• 部署后点开线上网址，逐个点一遍核心功能
• 如果是多页/SPA，刷新非首页路径不报 404

---

动手挑战

别只看，挑一个做了才算数：

1. 把你手上任意一个能跑的前端项目推到 GitHub，在一个前端平台上完整部署一次，拿到一个公网网址，发给一个朋友让他打开。
2. 故意制造一次"环境变量没配"的失败：在代码里读一个变量但平台不配它，看看线上会怎么报错、日志里长什么样——亲手踩一次，下次一眼就认得。
3. 进阶：同一个项目，分别部署到两家平台（比如 Vercel 和 Cloudflare Pages），对比一下构建速度和访问速度，体会它们的差别。

---

小结 · 你现在掌握了什么

• 你能分清"静态站"和"全栈应用"，知道前者随便哪个前端平台一键发、后者要管后端。
• 你走通了"连 git 仓库 → 自动构建 → 上线"的完整流程，看得懂构建日志，会配构建命令和环境变量。
• 你手里有一张选型表和一份 checklist，能避开构建失败、变量没配、路由 404 三大坑，也知道自有服务器贵在哪、什么时候才值得上。

部署是从"我做了个东西"到"别人真能用上"的第一道门槛。这道门跨过去，你的 MVP 才算真正存在于世界上。

下一步：站发上线后，你会想要一个像样的网址而不是一长串平台域名——去看本级域名 / HTTPS / DNS 那一节，把买域名、配解析、开 HTTPS 这条链路走通；想看自己在整条路上的位置，对照三支柱路线图。

👉 看看我们的 AI 编程实战体系课，或逛 AI 编程教程大全 把基本功打扎实。