第 8 章 · 部署上线与上线后验证
带数据库的产品上线需要什么资源、环境变量、配置；本地和线上有什么不同；怎么验证「真的上线成功了」。本章部署步骤为文档整理、未实测。
这一章解决什么问题
上线课教你把一张纯静态页面发上公网（那套流程本站 2026-09-17 实测走通过）。生词本这类带数据库和登录的产品，上线多了一批新问题：数据库放在哪？代码里写的「本地数据库地址」到了线上指向谁？登录成功后跳回哪个网址——本地是 localhost，线上呢？
这一章回答三件事：上线需要哪些资源、本地和线上有什么区别、上线后怎么验证「真的成了」。边界先说清：本教程不要求你真的创建生产环境。本章的部署步骤按 2026-09 官方文档整理、未实际执行——你可以拿它当操作地图，真上线时以当时的服务商文档为准。
开始前你要有什么
- 第 7 章本地验收全绿的项目（AC1–AC8 本地全过）
- 一个代码托管仓库（GitHub 等）——多数托管平台从这里拉代码
- 第 4 章选型对应平台的账号（案例为 Vercel + Supabase，都有免费档）
分工：人判断什么，AI 做什么
| 人负责（判断） | AI / Skills 负责（加工） |
|---|---|
| 选平台、注册账号、同意条款（账号操作必须本人完成） | 把部署文档整理成步骤清单 |
| 决定哪些值算「机密」、配在哪 | 帮你读报错日志、定位配置错误 |
| 宣告「上线成功」（以验证清单为准，不以界面为准） | 生成上线后验证清单 |
怎么做
第 1 步：盘点上线需要的资源（约 10 分钟）
对照这张表，缺哪个补哪个：
| 资源 | 生词本对应 | 放在哪 |
|---|---|---|
| 应用托管 | Next.js 前端+服务端 | Vercel（案例）/ 其他支持 Next.js 的平台 |
| 数据库服务 | words 表 | Supabase（案例），独立于应用托管存在 |
| 身份服务 | 邮箱登录 | 已含在模板的登录方案里 |
| 环境变量 | 数据库地址、登录密钥、回调网址 | 托管平台的项目设置里（不进代码仓库） |
| 域名（可选） | 一个好记的网址 | 不买也能上线，用平台送的二级网址 |
关键认知：数据库不跟着应用走。本地开发时数据库可以是 Supabase 的免费实例（或本地实例），线上用的是另一个（或同一实例的独立库）——总之「线上应用连哪个库」是一个配置问题，不是一个默认。
第 2 步：理解本地与线上的四个区别
| 本地 | 线上 | |
|---|---|---|
| 网址 | localhost:3000，只有你能开 | 公网网址，任何人可访问 |
| 环境变量 | .env 文件（在开发者电脑上） | 托管平台控制台里逐条配置 |
| 数据库 | 开发库（数据随便造、随便删） | 生产库（每一行都是真实数据） |
| 登录回调 | 跳回 localhost | 跳回线上网址——必须在登录服务里登记 |
第四行是新手最常踩的坑：登录服务的控制台里有一个「允许的跳转网址」清单，线上域名没加进去，上线后登录会直接报错——本地明明好好的。
第 3 步：环境变量——机密的交接方式（约 10 分钟）
你的项目里有一个 .env（或 .env.local）文件，长这样：
DATABASE_URL=postgresql://... # 数据库连接串：地址、账号、口令全在里面
AUTH_SECRET=一个随机长字符串 # 登录会话的签名密钥两条铁律：
.env永远不进 git（模板的.gitignore已包含，确认没被删）。泄露DATABASE_URL= 任何拿到它的人对你的数据库为所欲为；- 线上平台的环境变量要逐条重配。代码仓库不含
.env，所以部署后应用「看不到」任何变量——必须在平台控制台的项目设置里把同名变量一个一个填进去。变量名必须和代码里读的完全一致。
第 4 步：部署操作示例（按 2026-09 官方文档整理，未实测）
案例路线（Vercel 托管 Next.js + Supabase 数据库）的骨架步骤：
1. 代码推上 GitHub 仓库
2. Supabase 控制台：创建项目 → SQL Editor 执行 words 建表语句
（第 6 章的 DDL 就是为这一步准备的）
3. Vercel 控制台：导入 GitHub 仓库 → 平台自动识别 Next.js
4. Vercel 项目设置 → Environment Variables：逐条填入
DATABASE_URL、AUTH_SECRET 等代码需要的全部变量
5. 部署 → 平台分配一个 https://你的项目.vercel.app 网址
6. 登录服务配置：把线上网址加入「允许的跳转网址」清单
7. 打开线上网址走一遍登录（第一次会要求你确认邮箱等）每一步的入口和按钮位置以服务商当时的控制台为准——控制台改版是常态，所以本教程只给骨架不给截图：对照着找，找不到就把界面上的词抄下来问 AI「Vercel 里 XX 在哪」。
对比记忆：本站自己的上线（纯静态）只用了「构建出静态文件 → 上传」两步，因为静态页没有数据库和会话。你的生词本多出的 2、4、6 三步，全是「数据与身份」带来的——第 6 章讲的三层，上线时就是三个要各自接好的插头。
第 5 步：上线后验证——怎么才算「真的成了」
部署平台显示「Deployed ✅」只代表构建成功，不代表产品能用。上线成功的判据是把 AC 搬到线上重跑：
- 手机关掉 Wi-Fi 用流量打开线上网址（真正的「公网可达」测试）
- AC1：未登录访问 → 跳登录页
- AC2：线上录入一个词 → 列表出现
- AC3：换一台设备登录同一账号 → 词还在（跨设备是 D4/D5 的立身之本）
- AC8：第二个账号看不到第一个账号的词
- AC7：线上保存失败时（比如飞行模式）不假成功
全过，才算「上线成功」——把结果追加进 docs/验收记录.md，注明线上网址和日期。
然后启动两周试用（第 1 章埋的终极检验）：自己真实使用两周，对照第 1 章写下的「怎么判断有用」逐条核对——录入够 50 个词吗？复习时真的只看未掌握吗？ 假设在这里兑现或证伪，产品方向在这里调整。这是全教程的闭环：第 1 章写的判据，只有此刻才能打分。
第 6 步：常见失败与处置
| 症状 | 根因 | 处置 |
|---|---|---|
| 打开网址 500 / 「Application error」 | 环境变量漏配或名字对不上 | 平台设置里逐条核对变量名；补配后重新部署（改环境变量不会自动生效到已部署版本） |
登录报 redirect_uri_mismatch 一类 | 线上域名没登记进登录服务的跳转清单 | 回第 4 步第 6 项补登记 |
| 报「relation words does not exist」一类 | 建表语句没在生产库执行 | 回第 4 步第 2 项；本地跑过 ≠ 生产库有表 |
git push 后发现 .env 被提交了 | .gitignore 失效或被覆盖 | 立刻更换所有密钥（数据库口令、AUTH_SECRET），再清理仓库历史——视同泄露处理 |
第 7 步：上线之后的更新
改代码 → 本地验证 → 推送 → 平台自动重新部署（多数平台默认如此）→ 线上抽查一条 AC。两条纪律：
- 涉及表结构变更的更新（加字段、改约束）：先在生产库执行变更（Supabase 控制台 SQL Editor），再发布新代码——顺序反了，新代码访问旧表会当场报错；
- 每次更新后抽查，别默认「部署成功 = 没改坏」：发布不是终点，验证才是（第 7 章的规矩在线上同样有效）。
产物与检查
产物：上线清单执行记录 + 线上验收记录 + 两周试用计划。检查表：
- 环境变量全部配置且未进 git
- 线上 AC 验收清单（第 5 步）逐条有记录
- 手机流量 + 换设备两项物理测试做过
- 两周试用计划已启动（结束日期写进日历）
不满意或失败时怎么调整
- 部署反复失败：把构建日志报错原样喂给 AI（托管平台的构建日志就是证据）；连续失败时先本地
npm run build确认不是代码问题，再查平台配置。 - 上线后发现数据配错了库（比如连的还是开发库）：停用、改
DATABASE_URL、重部署，并核对两个库里的数据。生产环境的一切操作前，先确认连的是哪个库——养成看一眼环境变量再动手的习惯。 - 两周试用结论是「我没在用」：这是有效的验证结论，不是失败。回第 2 章决策表：是录入太麻烦（D2）、复习形态不对（D3）、还是需求本身不成立？砍范围或换方向，都比硬着头皮加功能诚实。
交给下一章什么
- 完整的八步方法论——下一章把它原样搬到你自己的产品上；
- 你踩过的坑——迁移练习里最值钱的输入：哪一章你卡得最久，换产品时就先补哪章的功课。
案例进度：方法论全部走完。最后一章不是案例，是你的战场。