本文由 莫潇羽@源码七号站（www.fuyuan7.com）撰写，转载请注明出处。
快速摘要
如果你手里有一个开源的 Web 项目，不想买服务器，也不想折腾 Nginx 反向代理和 SSL 证书，那么这篇文章就是为你准备的。本文以一次真实的全栈项目部署经历为线索，系统梳理了三种主流部署路线：Serverless 平台（Vercel / Netlify）一键部署、Docker 容器化自托管部署、以及用 Upstash Redis 做数据持久化的进阶玩法。每种方式都有完整的操作步骤、配置代码、以及我亲自踩过的坑。看完你会对现代 Web 应用的部署生态有一个清晰的全局认知——不再只会在本地 npm run dev，而是能把项目真正送上线。
这年头，前端圈的变化快得让人喘不过气。几年前大家还在争论 Webpack 配置怎么写，一转眼 Vite 已经成了标配。以前部署一个项目得上服务器、配 Nginx、申请 SSL 证书、搞 CDN——一套流程走下来，没半天搞不定。现在呢？把代码推到 GitHub，连上 Vercel，几分钟后一个带 HTTPS 和全球 CDN 的网站就上线了。这种体验上的反差，说实话，我刚接触的时候也被震撼到了。
我就是莫潇羽，源码七号站（www.fuyuan7.com）的站长。平时折腾各种开源项目，积累了一些部署方面的实操经验。写这篇文章的目的很简单：把我折腾过的几种部署方式整理成一份系统化的参考手册，让你下次遇到类似需求的时候不用到处搜零零散散的教程，一篇就够了。
想看完整的拆解过程？往下翻，我们从基础概念开始，一步步把每种部署路线走通。
前置知识：理解现代 Web 应用的架构骨架
在动手部署之前，有几样东西得先搞清楚。这些东西不是什么高深理论，但如果不了解，后面看配置文件和部署步骤的时候会一头雾水。我用最简单的话把核心概念串一遍。
Next.js 到底是啥？
很多时候我们说的"Web 应用"，现在已经不是十年前那种 HTML + CSS + jQuery 的组合了。现代 Web 应用通常基于某种全栈框架构建——一套代码里同时包含前端界面和后端接口。
Next.js 就是这类框架里的明星选手。它基于 React，但又比纯粹的 React 多了一层"服务端能力"。你用 Next.js 写的项目，既可以走传统的客户端渲染（CSR），也可以走服务端渲染（SSR），甚至可以生成纯静态页面（SSG）。同一个项目，部署的时候灵活性极高——你可以把它丢到 Vercel 这种 Serverless 平台上跑，也可以打包成 Docker 镜像在自己的 NAS 或 VPS 上跑。
我自己的理解：Next.js 就像一辆既能在高速公路上飙（Vercel 优化），也能在乡间小路上开（自托管 Docker）的车。这种灵活性，对于学习和实验来说简直完美。
环境变量：应用的"身份信息"
任何一个正经的 Web 应用都不会把密码、密钥、数据库地址硬编码在源码里。这些东西通过环境变量注入——运行的时候由部署平台或容器把值传进去。
环境变量本质上就是一组 key-value 键值对，比如：
USERNAME=admin
PASSWORD=mySecret123
REDIS_URL=redis://localhost:6379在 Vercel 或 Netlify 的网页后台，你可以在项目设置里找到"Environment Variables"面板，一个个填进去。Docker 部署时，这些变量写在 docker-compose.yml 的 environment 字段里。格式不同，原理一样。
数据持久化的三种姿势
一个 Web 应用运行起来之后，用户的操作数据、配置信息得有个地方存。常见的选择有三种：
方案 | 原理 | 适用场景 | 优点 | 缺点 |
localStorage | 数据存在浏览器本地 | 单设备使用、无需同步 | 零配置，无需后端 | 换设备数据丢失，不能多设备同步 |
自建 Redis | 内存数据库，数据存在服务器上 | Docker 部署、有 VPS/NAS | 高性能，数据可持久化 | 需要自己维护 Redis 实例 |
Serverless Redis（如 Upstash） | 云端的 Redis 服务，按请求量计费 | Vercel/Netlify 等 Serverless 平台 | 免运维，与 Serverless 平台深度集成 | 请求量大时成本上升（但有免费额度） |
这个对比对你选择部署路线很重要。如果你只是在个人电脑上玩一玩，localStorage 够用了；如果你有多设备同步的需求（比如家里 NAS + 手机都想访问同一个应用），那 Redis 方案就是必须的。
现代部署平台的能力边界
下面这张表是我根据自己的使用体验总结的，可以帮助你快速判断哪种平台适合你：
平台 | 部署门槛 | 费用 | 自定义程度 | 适合人群 |
Vercel | ⭐（极低） | 免费额度够个人用 | 中 | 前端开发者、不想碰服务器的同学 |
Netlify | ⭐（极低） | 免费额度够个人用 | 中 | 已有 Netlify 账号、偏好其生态的用户 |
Docker（自托管） | ⭐⭐⭐（中等） | VPS/NAS 硬件成本 | 高 | 有 NAS 或 VPS、喜欢折腾的玩家 |
好，基础概念就讲到这儿。现在你已经知道了 Next.js 是干什么的、环境变量怎么工作、数据该存到哪、以及不同平台的定位。接下来我们正式进入部署实操。先从最友好的 Vercel 路线开始。
部署方式一：Serverless 平台部署——Vercel 路线
Vercel 是 Next.js 框架背后的公司开发的部署平台。因为它和 Next.js 是"亲父子"关系，所以用 Vercel 部署 Next.js 项目的体验是所有平台里最丝滑的，没有之一。你不需要知道什么是 Nginx，不需要理解反向代理，甚至连域名都可以先不绑——Vercel 直接给你一个 xxx.vercel.app 的免费域名。
Vercel 的工作机制：一个直观的理解
你往 GitHub 仓库 push 代码 → Vercel 自动检测到变更 → 拉取代码 → 执行构建 → 部署到全球 CDN 节点 → 返回给你一个可访问的 URL。
整个过程你不需要碰任何服务器。这背后是 Serverless 架构在起作用：Vercel 把你的应用拆成一个个无状态的函数，按需执行，不跑的时候不占资源。对于个人项目和学习实验来说，这意味着你几乎可以零成本地把项目跑起来。
第一步：准备 GitHub 仓库
几乎所有现代化部署平台都跟 GitHub 深度绑定。所以第一步是把你要部署的项目代码放到 GitHub 上。
如果你的项目源码已经在某个开源仓库里，最标准的做法是 Fork（复刻）一份到你自己的 GitHub 账号下。Fork 的好处是：你得到了一份完全由你控制的副本，可以自由修改配置文件，同时又保留了对原始仓库的追溯。而且后续原始仓库如果有更新，你可以通过 GitHub 的 Sync fork 功能同步过来，非常方便。
Fork 的操作很简单：打开原始仓库页面，点右上角的 Fork 按钮，选择你的账号作为目标，几秒钟就完成了。Fork 完之后，你会在自己账号下看到一个同名的仓库，URL 变成了 https://github.com/你的用户名/项目名。
莫潇羽的小提示：Fork 之后记得先看一眼仓库里的 config.json 或类似的配置文件。很多开源项目的默认配置不一定符合你的使用习惯，部署前改好比部署后再改要省事得多。第二步：登录 Vercel 并授权 GitHub
打开 Vercel 官网，点右上角的 Login。Vercel 支持 GitHub、GitLab、Bitbucket 三种登录方式。我个人建议直接用 GitHub 登录——因为你的代码就托管在 GitHub 上，用同一个账号授权最省事。
登录之后 Vercel 会请求访问你的 GitHub 仓库权限。这里需要注意：Vercel 默认会请求访问你所有仓库的权限，但你可以在授权时选择"Only select repositories"，只勾选你 Fork 的那个仓库。从安全角度说，这是一个好习惯——最小权限原则，不给平台多余的访问权限。
第三步：导入项目并配置
登录后进入 Vercel 的 Dashboard，点击 "Add New..." → "Project"，你会看到一个仓库列表。找到你刚才 Fork 的那个仓库，点击 "Import"。
接下来是关键一步——设置环境变量。Vercel 会自动识别你的项目是 Next.js 框架，所以构建命令、输出目录这些都不用你管。但你需要手动填写项目运行所必需的环境变量。
什么是必需的环境变量？每个项目不一样，但通常至少包含一个用于访问控制的密码。设置方法：在 "Environment Variables" 区域，Name 填变量名（比如 PASSWORD），Value 填你设定的密码值。点击 Add 可以继续添加更多变量。
这里给一个典型的配置示例：
PASSWORD = your_secure_password_here填好之后点 Deploy。Vercel 会开始构建你的项目——拉取代码、安装依赖、执行构建——你可以在构建日志里实时看到进度。一般一两分钟就完成了。
部署成功后，Vercel 会给你一个类似 https://你的项目名.vercel.app 的域名。点击就能直接访问。
第四步：绑定自定义域名（可选但推荐）
Vercel 送的 .vercel.app 域名虽然能用，但如果你有自己的域名，绑上去体验会好很多——特别是国内访问时，用自己的域名配合合适的 DNS 解析策略可以改善访问速度。
绑定步骤：
- 进入项目 Settings → Domains
- 输入你的域名，点击 Add
- Vercel 会给你一组 DNS 记录配置信息（通常是 CNAME 记录）
- 去你的域名 DNS 管理后台（阿里云、腾讯云、Cloudflare 等等），添加对应的解析记录
- 等待 DNS 生效（快则几分钟，慢则几小时），Vercel 会自动申请并配置 SSL 证书
绑定完之后，你的项目就有 https://你的域名.com 这样的正式地址了。
第五步：自动部署——改代码即上线
Vercel 最让我喜欢的一个特性是自动部署。你把 Fork 的仓库 clone 到本地，改了代码，push 到 main 分支——Vercel 检测到变更后会自动触发重新构建和部署。你不需要手动点任何按钮。
这个特性对于持续迭代的项目简直太爽了。你改一个配置、修一个 bug、加一个新功能，push 之后喝杯水的功夫，线上就已经更新好了。而且 Vercel 对每个 commit 都会生成一个独立的预览 URL，你可以先预览确认没问题再合并到主分支。
我个人的 Git 工作流建议：不要直接在 main 分支上改东西。建一个 dev 或 feature/xxx 分支，改完测试好，再合并到 main。这样 main 分支始终是一个稳定可部署的状态，不会出现"改了一半不小心推上去导致线上炸了"的尴尬。Vercel 默认只监听 main 分支的变更，但你可以配置它也监听其他分支（作为预览部署），灵活度很高。
关于国内访问的补充说明
实话实说，Vercel 默认分配的域名在国内某些网络环境下的访问体验参差不齐。这不是 Vercel 的问题，而是跨境网络的固有特征。我的经验是：
- 绑了自己的域名之后，配合国内 DNS 服务商做解析，情况会好不少
- Vercel 的全球 CDN 节点在亚洲有部署（新加坡、香港、东京等），大部分请求能就近响应
- 如果对国内访问速度有极致要求，可以将 Docker 自托管部署作为备选方案（后面会讲）
合规提示：Vercel 为境外平台，使用时请遵守国内网络与内容管理相关规定。本文讨论的是技术学习层面的部署实践，不涉及任何特定内容的传播引导。
进阶配置：用 Upstash Redis 实现数据持久化
前面说了，localStorage 模式最大的问题是数据存在浏览器里——换一台设备、清一次缓存，数据就没了。如果你的应用有多设备同步的需求（比如家里电脑和手机都想访问同一个实例），那就得上 Redis。
Redis 是什么？一句话说清楚
Redis 是个内存数据库。跟传统的 MySQL、Pos
