--- title: "第十二章：无服务器部署与 CI/CD 自动化" --- # 第十二章：无服务器部署与 CI/CD 自动化 ![img](/images/Advanced/mll089oi-6566edafa4114ef0.jpg) ## 序言 小明的"个人豆瓣"代码已经推到 GitHub 上了，还和朋友通过分支和 PR 协作了几次。一切看起来很顺利——直到朋友发来消息："你上次用 Tunnel 给我看的那个链接打不开了，能不能弄个一直能用的？我想发给我女朋友看看。" 小明一愣。第十章用 Cloudflare Tunnel 临时分享的链接，关了终端就失效了。他需要一个**永久在线**的地址——任何人、任何时候都能打开。 这就是"部署"要解决的问题。 ### 零成本部署 老师傅给你推荐了一套零成本起步方案：选择一个**部署平台** + 一个**数据库托管服务**。 **部署平台**负责运行你的前端和后端代码，提供 **Serverless (无服务器)** 环境。注意，Serverless 不是说没有服务器，而是**你不需要管理服务器**。你只管写代码，平台的扩容、维护全交给它处理。 主流的部署平台有： - **腾讯云 EdgeOne Pages**：国内可访问，基于腾讯全球边缘网络，连接 GitHub 后自动部署，对 Next.js 支持很好 - **阿里云 ESA 函数和 Pages**：阿里云的一站式全栈开发平台，深度集成 Git 工作流，国内访问速度快 - **Vercel**：Next.js 的官方部署平台，体验极佳，但国内访问较慢，适合海外用户或有自定义域名的项目 - **Cloudflare Pages**：全球 CDN 加速，免费额度慷慨，支持边缘函数 - **GitHub Pages**：最简单的静态网站托管，适合纯前端项目 **数据库托管**负责存储你的数据。老师傅推荐你用 **Neon**——它是一个专注于 PostgreSQL 本身的云服务，提供无服务器架构，可以按需自动扩缩容。最重要的是，它就是标准的 PostgreSQL，你用 **Drizzle ORM** 通过标准连接字符串去连接，完全不涉及任何厂商捆绑。这样哪天你想换数据库服务商，只需要把 `DATABASE_URL` 一改就行，这叫**保持架构的独立性**。 如果你需要更多后端功能（比如 Auth 认证、Storage 存储、Realtime 实时订阅），也可以考虑 **Supabase**。它本质上就是一个**云端的 PostgreSQL** 加上一套后端服务。但老师傅提醒你，尽量用 Drizzle ORM 直连数据库，而不是大量使用 Supabase 独有的 JS SDK，这样才能保持迁移的灵活性。 ### CI/CD 自动化 老师傅还提到了一个听起来很高级的词：**CI/CD（持续集成/持续部署）**。 虽然听起来复杂，但在现在的开发流程里，它就意味着**"自动化"**。 以前，部署网站需要：`手动打包 -> 传到服务器 -> SSH 登录服务器 -> 重启服务`。 现在，流程变成了： 1. 你在本地运行 `git push` 把代码推送到 GitHub。 2. GitHub 自动通知部署平台："嘿，有新代码了！" 3. 部署平台收到信号，自动拉取最新代码，下载依赖，运行构建，发布上线。 你不需要懂复杂的运维命令，**保存即发布**。 CI/CD 让部署变成了"保存即发布"。老师傅告诉你，这种"代码变更时自动触发操作"的理念，和我们在开发时提到的 **Hooks** 是完全一致的。在本地，Hooks 自动运行测试和格式化；在云端，CI/CD 自动运行构建和部署。它们构成了完整的自动化闭环。 **部署生命周期**：完整的部署流程包括几个阶段——你在本地开发写代码，推送到 GitHub 后自动触发构建，构建成功后会生成一个预览链接（国内平台通常是 3 小时有效期），确认没问题后合并到主分支就正式上线了。当部署记录超过一定数量后，旧的部署会被标记为失效，这能帮你节省存储空间。 ### 部署配置 在开始部署之前，老师傅告诉你需要先了解几个核心配置参数。虽然现代部署平台能自动识别很多项目，但理解这些参数能让你在出问题时知道如何排查。 **构建设置**： - **框架预设**：选择你用的框架（如 Next.js），平台会自动填充推荐配置 - **根目录**：代码在仓库里的位置，默认是仓库根目录 `./` - **构建命令**：默认是 `npm run build` 或 `pnpm build` - **输出目录**：构建产物存放的位置，Next.js 通常是 `.next` 或 `out` - **Node 版本**：平台预装了多个 Node 版本（如 18、20、22、24），本教程使用的是 24 大版本 **环境变量**：部署后需要单独配置。国内平台通常支持批量导入——直接把 `.env` 文件的内容粘贴进去，平台会自动识别。注意环境变量的修改只对新部署生效，不会影响已有部署。 ### 部署踩坑 你学会了将 GitHub 项目绑定到部署平台，点击"部署"按钮，第一次构建启动了。 **坑一：Node.js 版本不一致** 红色的 **Failed** 给了你当头一棒。查看日志，发现是 Node 版本太旧导致的。部署平台默认的 Node 版本可能比较老，而你的 Next.js 项目需要更新的版本。你需要在平台的设置里把 Node.js Version 调整为和你本地一致的版本（本教程是 24），然后重新部署。 **坑二：环境变量失踪** 修正版本后，构建成功了，但访问网页全是报错。你猛然想起第六章学过的知识：**`.env` 文件被 `.gitignore` 拦在门外了！** GitHub 上根本没有你的数据库密码和 API Key。你需要在平台的"环境变量"页面，把本地 `.env` 里的内容一条条复制填进去。 国内平台通常支持批量导入——直接粘贴整个 `.env` 文件的内容，平台会自动识别。 配置好变量后，你满怀期待地再次访问，网页终于正常显示了。因为你一直用的就是云端数据库，代码和数据都在那里，部署只是换了一个运行代码的地方。 **部署成功** 一切配置妥当后，部署平台给你生成了一个访问链接。你激动地点开，网页在公网上跑起来了，终于获得了那个可以发给朋友的链接。 ### 灰度发布——降低风险 部署成功后，老师傅提到一个进阶策略："如果你的产品有大量用户，直接推送新功能风险很大。万一有严重 Bug，影响所有用户。" **灰度发布** 的做法是：先给 10% 的用户推送新版本，观察几天没问题，再扩大到 50%，最后全量。这就像先在小范围试吃，确认没问题再大规模推广。 这能让你在发现问题及时止损，而不是一次性把所有用户都暴露到风险中。好消息是，一些部署平台支持这个功能，让 AI 帮你配置即可。 个人项目阶段不需要这么复杂，但理解这个概念有助于理解大厂的做法——为什么你有时候能用上新功能，有时候不能，因为你在不同的灰度批次里。 ### 平台自动优化 部署成功后，老师傅告诉你一个好消息：**这些平台已经帮你做了很多性能优化**。 比如图片会自动压缩成更高效的格式，代码会自动分割成小块按需加载，静态资源会被分发到全球的加速节点。你不需要自己配置这些，平台默认就帮你做好了。 当然，如果你的产品用户量很大，这些默认优化可能不够。那时候你再考虑更深入的优化策略。但在早期阶段，平台的默认设置已经足够好了。 ### CDN 老师傅顺便提到了一个重要概念：**CDN（内容分发网络）**。当你把网站部署到公网后，你可能会发现——国内访问快，国外访问慢。这是因为物理距离限制了传输速度，数据绕地球半圈需要时间。 CDN 的原理是在全球各地部署"缓存服务器"。当用户访问你的网站时，CDN 会自动从离用户最近的服务器返回内容，而不是每次都请求源服务器。这就像在各地开了分店，用户去最近的分店而不是总部。 现代部署平台（EdgeOne、ESA、Vercel、Cloudflare 等）都内置了 CDN，你不需要额外配置。理解这个原理后，你就知道为什么网站能在全球快速访问了。 ### 缓存的三层防护 老师傅说："缓存无处不在，它让网站更快。" 你会遇到三类缓存： 1. **浏览器缓存**：访问过的资源存在本地，下次不用重新下载。你在第四章已经体验过——改了代码刷新还是旧的，因为缓存了。 2. **CDN 缓存**：刚才讲的全球节点缓存，离用户最近。 3. **服务端缓存**：服务器内存里缓存计算结果或数据库查询结果，避免重复计算。你可能注意过，第一次打开某个页面比较慢，之后再打开就快了——即使清了浏览器缓存也是如此，这往往就是服务端缓存在起作用。 大部分缓存都是自动的。缓存的核心思想很简单：**把常用的东西存起来，下次直接用**。有时候网站更新了用户看不到，可能就是缓存没刷新，清除缓存或强制刷新（Ctrl+Shift+R）就能解决。 ### 成本优化 产品上线一段时间后，你打开账单一看，数字让你心跳加速。老师傅告诉你，这时候需要建立**成本优化意识**。 关于部署决策，老师傅说要分阶段考虑。MVP阶段（<1000用户）用Serverless零成本起步，不要过早优化。增长期（1000-10000用户）评估混合架构，如果成本增长过快再考虑自建。企业期（>10000用户）才需要为合规或性能优化自建服务器。**过早优化是万恶之源**，不要在阶段一就担心阶段三的问题。 AI模型成本也值得优化。简单任务用便宜的国产模型（如GLM、DeepSeek），复杂推理用Claude。你可以在代码里加一层判断：简单的翻译、摘要请求发给便宜模型，需要深度推理的请求才发给 Claude——这就是"智能路由"。某AI应用通过智能路由（70% GLM + 30% Claude），API成本降低了80%。关键是匹配任务复杂度和模型能力，不要用大炮打蚊子。 老师傅还提醒你注意**免费额度陷阱**：很多平台的免费额度只够测试用，一旦有真实用户，费用会指数级增长。记得设置账单告警（比如"超过¥70发邮件提醒"），定期查看用量，做到心中有数。免费额度是用来体验的，不是用来长期跑生产业务的。 至于运维监控、日志分析等SRE相关的技术实践，我们会在后续云服务器运维中详细讲解。 ## 本章学习路径 1. [部署到 EdgeOne Pages](./01-deploy-edgeone.md) → 手把手完成第一次部署，拿到公网链接 2. [部署到类 Vercel 平台](./02-deploy-vercel-platforms.md) → 了解更多平台选择，找到最适合你的 3. [CI/CD 与自动化](./03-cicd-automation.md) → 推送即部署，让自动化接管重复劳动 4. [运维基础与成本优化](./04-operations-cost.md) → 上线之后谁来看着它，怎么控制成本 **AI 编程时代的部署**：告诉 AI 目标平台，它会帮你完成配置和部署。 --- **上一章**：[第十一章：Git 版本控制与跨平台协作](../11-git-collaboration/index.md) **下一章**：[第十三章：域名、DNS 与 HTTPS](../13-domain-dns/index.md)