第十部分 · Docker 与部署

到现在，你的 AI Todo 已经是一个工程化良好的完整应用：Vue + Tailwind 的前端、FastAPI + Pydantic 的后端、SQLite（或 PostgreSQL）存数据，还接上了大模型。但它有一个尴尬的局限——只能在你自己这台电脑上跑。这一部分，我们要让它走出你的电脑，最终部署到公网，让全世界任何人打开链接都能用。

关于这一部分怎么用

这一部分技术名词会多一点，但别慌。你要做的事和前面完全一样：把需求讲清楚，让 AI 写配置和脚本，你负责一件件验收。原理我们只讲到「够你判断结果」为止，写 Dockerfile、写 docker-compose、写部署脚本这些又细又碎的活，全部交给 Claude Code / Codex。

我们的技术路线是一条清晰的直线：

理解部署是什么
   ↓
Docker（把应用打包成集装箱）
   ↓
Docker Compose（一份配置管好前端+后端+数据库）
   ↓
一键启动整套应用
   ↓
部署到云服务器（搬上公网）
   ↓
域名 + HTTPS + 日志（起个好名字、加把安全锁、装个行车记录仪）
   ↓
部署结果验收

⚠️ 这一部分从头到尾都在跟「上线」打交道。请先记住一条铁律，后面还会反复提醒：API Key、数据库密码这类敏感信息，一定要用环境变量管理，绝不能写死在代码里，更不能提交到公开仓库。 一旦泄露，别人可以拿你的 Key 疯狂调用，账单算你的。

55. 部署是什么

这一章要解决什么问题

先把「部署」这个词讲明白。很多初学者对它有种莫名的恐惧，觉得是高深的运维工作。这一章告诉你：它其实只在解决一件你早就想要的事。

这是什么：从「我自己能用」到「别人也能用」

一句话说清楚：

部署 = 让你的应用从「只有我自己的电脑能打开」，变成「别人也能打开」。

现在你的 AI Todo 是怎么跑的？你在终端敲一条命令把它启动，然后在浏览器访问 http://localhost 看到它。但 localhost 是「我自己这台电脑」——你把这个地址发给朋友，他打不开，因为那指的是他的电脑，不是你的。

部署要做的，就是把你的应用搬到一台一直开着、且公网能访问的电脑（我们叫它「服务器」）上，再给它一个别人也能打开的地址。

为什么现在需要它

回想一下你这一路做出来的东西：能增删改的界面、会拆解任务的 AI、能存数据的数据库……这么好用的东西，只躺在你自己电脑里，关机就没了、换台电脑就没了、想给别人看只能截图，太可惜了。

而且你可能早就撞过那面墙：把项目拷给同学，或者换到另一台电脑，结果——「在我电脑上明明好好的，换台机器就跑不起来」。这句程序员的经典抱怨，正是接下来 Docker 要替我们根治的。部署，就是把这两个痛点一起解决掉。

部署大概要经历哪几步

别怕，就四步，后面每一章拆开讲：

打包：把应用连同它需要的环境一起打包好（用 Docker）。
搬运：把打包好的东西传到一台公网服务器上。
启动：在服务器上一条命令拉起整套应用（用 Docker Compose）。
访问：配好地址（域名 + HTTPS），别人就能打开了。

本章小结

部署不神秘，它只做一件你早就想做的事：让你的 AI Todo 从「自己玩」变成「大家用」。接下来的每一章，都是在完成这四步中的一步。

56. Docker 是什么

这一章要解决什么问题

解决那句经典抱怨——「在我电脑上明明好好的，换台机器就跑不起来」。这一章我们请出根治它的主角：Docker。

这是什么：一个打包好的集装箱

你的应用能在你电脑上跑，是因为你电脑里恰好装好了对的 Node、对的 Python、对的一堆依赖、对的配置。换一台电脑，这些环境哪怕差一点点，就可能跑不起来。

Docker 的思路特别妙：

💡 既然环境这么难对齐，那就干脆把「应用 + 它需要的整个环境」一起打包成一个箱子，搬到哪儿就在哪儿原样运行。

这个「箱子」就像海运的集装箱。集装箱最伟大的地方在于：不管箱子里装的是家具、水果还是机器，货轮、码头、卡车都用同一套标准去搬运，不用关心里面是什么。Docker 就是软件世界的集装箱——不管你的应用用什么语言、什么依赖，装进 Docker 这个箱子后，任何装了 Docker 的机器都能原样把它跑起来。

几个词你听一下就好，不用背：

镜像（Image）：打包好的那个「箱子」本身，是个静态的模板。
容器（Container）：把箱子拆开、真正跑起来的那个运行实例。
Dockerfile：一张「打包说明书」，告诉 Docker 该怎么把你的应用装进箱子。

打个比方：镜像像一份冷冻速食，容器像你把它加热后端上桌的那盘菜，Dockerfile 则是这份速食的制作配方。

为什么现在需要它

因为你马上要把应用搬到别人的服务器上。没有 Docker，你得在那台陌生的服务器上，把 Node、Python、各种依赖一个个重新装对——极其容易出错，就是「换台机器跑不起来」的重灾区。有了 Docker，你只要保证那台服务器装了 Docker，剩下的箱子一搬就能跑，环境永远一致。

在 AI Todo 里怎么用

我们让 AI 给项目写好 Dockerfile（打包说明书），先拿后端练手：把 FastAPI 后端打包成一个镜像，再在容器里跑起来，用浏览器验证它确实活着。前端我们下一章连同 Compose 一起处理。

让 AI 执行的小任务

先装好 Docker（如果还没装，直接让 AI 给你对应系统的安装命令）。然后在项目里启动 Claude Code / Codex，把这个任务提示词发给它：

任务目标：
给我的 AI Todo 后端写一个 Dockerfile，把它打包成一个可以运行的镜像。

当前状态：
我有一个 FastAPI + Pydantic 的后端，用 SQLite 存数据，本地能正常跑。
我完全不懂 Docker，机器上已经装好了 Docker。

限制条件：
先只打包后端这一个服务，前端和数据库这次先不管。
所有敏感信息（比如大模型 API Key）不要写死在 Dockerfile 或代码里，
要通过环境变量传入。

期望结果：
1. 项目里多出一个 Dockerfile。
2. 你告诉我用哪条命令把它打包成镜像。
3. 你告诉我用哪条命令把镜像跑成容器，并把端口映射出来。

验收标准：
1. 打包命令能成功执行，最后提示镜像构建完成。
2. 运行命令后，容器能起来不报错。
3. 我在浏览器访问后端地址（比如接口文档页 /docs），能正常打开。
4. 整个过程我不需要手动去装 Python 和依赖，Docker 全包了。

运行后应该看到什么结果

项目里出现一个 Dockerfile。
你按 AI 给的命令「构建」镜像，终端刷一大串日志后提示成功。
你按 AI 给的命令「运行」容器，后端启动。
浏览器打开后端地址（比如 http://localhost:8000/docs），能看到接口文档页。

💡 这里藏着一道选择题的答案：为什么不直接在服务器上装 Python？因为「装环境」这件事又慢又容易出岔子。我们选择用 Docker 把环境一次性封进箱子——一次打包，处处能跑。

如何验收结果是否正确

镜像构建成功了吗？
容器跑起来没报错吗？
浏览器能访问到容器里的后端吗？
你全程有没有手动装 Python / 依赖？（应该没有，Docker 全包了才算对。）

关键的一条：你没装 Python，后端却跑起来了——这就是集装箱的威力，环境被封进箱子了。

如果结果不对，怎么反馈给 AI

比如构建失败，或者容器起来了但浏览器访问不到：

我按你给的命令构建镜像并运行了容器，但在浏览器访问 http://localhost:8000/docs 打不开。
容器运行时的日志是这段（原文粘贴）：
<把日志粘在这里>
请判断是端口没映射、还是服务没起来，帮我修好，并再给我一遍正确的运行命令。

本章小结

Docker 是软件世界的集装箱，把「应用 + 环境」一起打包，从此「换台机器跑不起来」成为历史。你已经让 AI 把后端装进箱子，并在容器里跑通了。下一步，我们要用一份配置，把前端、后端、数据库三个箱子一起管起来。

57. Docker Compose 是什么

这一章要解决什么问题

上一章你跑起来一个容器。但我们的 AI Todo 有三个部分：前端、后端、数据库。难道每个都手动敲一长串命令、还要手动把它们连起来？太累也太容易错。这一章解决「多个服务怎么一起管」。

这是什么：一张乐队总谱

如果每个容器都单独启动、单独配置、单独告诉它「你去连那个数据库」，那就像一支乐队里每个乐手各弹各的，没人指挥，注定乱套。

Docker Compose 就是那份乐队总谱：

💡 你把「有哪些服务、每个服务怎么起、它们之间怎么连」全写进一份配置文件里，然后一声令下，所有服务像乐队一样同时、协调地开始演奏。

这份配置文件通常叫 docker-compose.yml。在里面，前端是一个乐手、后端是一个乐手、数据库是一个乐手，总谱里写清楚每个乐手用哪个镜像、开哪个端口、谁要连谁。指挥棒一挥（一条命令），整个乐队齐奏。

为什么现在需要它

因为真实应用几乎从来不是「一个服务」孤零零地跑，而是好几个服务配合。手动一个个启动、再手动把它们接起来，既繁琐又极易出错——今天忘了先起数据库，明天忘了配后端连数据库的地址。Compose 把这一切固化进一份文件，从此启动整套应用只需要一条命令，而且每次都一模一样。

在 AI Todo 里怎么用

我们让 AI 写一份 docker-compose.yml，把三个服务都写进去：

前端（Vue 打包后的静态页面）
后端（上一章打包好的 FastAPI）
数据库（这里正好可以升级用 PostgreSQL，也可继续用 SQLite）

并在总谱里配好：前端能访问到后端、后端能连上数据库、敏感信息通过环境变量注入。这一章我们先把这份「总谱」写出来、看懂它大概长什么样；下一章再真正挥棒，一条命令拉起整个乐队。

让 AI 执行的小任务

任务目标：
给我的 AI Todo 写一份 docker-compose 配置，把前端、后端、数据库三个服务统一管理起来。

当前状态：
- 前端是 Vue + Tailwind，需要打包成静态页面对外提供。
- 后端是 FastAPI，上一章已经有能用的 Dockerfile。
- 数据库我想用 PostgreSQL（如果你觉得先用 SQLite 更简单也可以说明）。
我不懂 Docker Compose。

限制条件：
- 所有敏感信息（大模型 API Key、数据库密码）都通过环境变量传入，
  绝对不要写死在 docker-compose 文件里，也不要提交到仓库。
- 请配套给我一个 .env 示例文件（比如 .env.example），并把真正的 .env 加入 .gitignore。

期望结果：
1. 项目里多出一个 docker-compose.yml，里面有前端、后端、数据库三个服务。
2. 配置里写清楚了前端如何访问后端、后端如何连接数据库。
3. 有一个 .env.example 说明需要我填哪些敏感信息。

验收标准：
1. docker-compose.yml 文件结构清晰，三个服务都在。
2. 文件里看不到任何真实的密码或 API Key，都是从环境变量读取。
3. 你用大白话给我讲一遍：这三个服务分别是干嘛的、它们怎么连起来。

运行后应该看到什么结果

项目里出现 docker-compose.yml 和 .env.example。
打开 docker-compose.yml，能看到大致分成三块（前端 / 后端 / 数据库），你不用看懂每一行，但能认出「哦，这三块对应我的三个服务」。
文件里的密码、Key 都是类似 ${DB_PASSWORD} 这样的占位，而不是真实值。

如何验收结果是否正确

有 docker-compose.yml 且包含三个服务了吗？
有 .env.example 告诉你要填哪些敏感信息吗？
文件里确实看不到任何真实密码 / Key 吗？
AI 有没有用大白话把三个服务和它们的关系讲清楚？

⚠️ 第三条是这一章最重要的验收点。亲自打开文件扫一眼，确认没有任何真实的密码或 API Key 明晃晃地写在里面。这个习惯，能帮你躲过初学者最容易踩的安全大坑。

如果结果不对，怎么反馈给 AI

比如你发现文件里把数据库密码写死了：

我打开 docker-compose.yml，发现数据库密码是直接写在里面的明文。
请改成从环境变量读取，把真实密码挪到 .env 里，
并确认 .env 已经被 .gitignore 忽略、不会被提交。

本章小结

Docker Compose 是管理多个服务的「乐队总谱」，一份配置写清楚前端、后端、数据库怎么起、怎么连。你已经有了这份总谱。下一章，我们挥下指挥棒——一条命令让整个乐队齐奏。

58. 一键启动前端、后端、数据库

这一章要解决什么问题

总谱写好了，这一章就干一件让人上瘾的事：一条命令，把前端、后端、数据库三件套同时拉起来，然后在浏览器里验证整套应用真的活了。

这是什么

有了上一章的 docker-compose.yml，启动整套应用就浓缩成一条命令（通常是 docker compose up）。敲下它，Docker 会照着总谱，把三个服务依次、协调地启动起来，还自动把它们连好。你会第一次真切感受到「工程化」带来的爽感——以前要开好几个终端、记好几条命令，现在一条搞定。

在 AI Todo 里怎么用

我们让 AI 把这套「一键启动」的流程和命令交代清楚，包括：先填好 .env 里的敏感信息、用哪条命令启动、怎么看三个服务是不是都起来了、怎么优雅地停下来。然后你亲手跑一遍，在浏览器里把整个应用从头到尾用一遍：增删改、AI 拆解任务、刷新看数据还在不在。

让 AI 执行的小任务

任务目标：
教我用一条命令，通过 docker-compose 把前端、后端、数据库整套应用启动起来。

当前状态：
项目里已经有 docker-compose.yml 和 .env.example，我还没填 .env，也没启动过。
我不懂命令，请手把手告诉我每一步。

限制条件：
不要让我手动一个个去启动服务，目标就是「一条命令拉起全部」。
启动前需要我做什么准备（比如复制 .env.example 成 .env 并填好），请明确列出来。

期望结果：
1. 你告诉我启动前要准备什么（尤其是 .env 里要填哪些值）。
2. 你给我一条启动整套应用的命令。
3. 你告诉我怎么确认三个服务都成功起来了。
4. 你告诉我怎么停止整套应用。

验收标准：
1. 我复制 .env.example 成 .env 并填好敏感信息。
2. 执行你给的那一条命令后，前端、后端、数据库三个服务都起来了。
3. 浏览器打开前端，能正常添加、删除、标记完成任务。
4. AI 拆解任务的功能能正常用。
5. 添加几条任务后刷新页面，数据还在（说明真的存进数据库了）。

运行后应该看到什么结果

你把 .env.example 复制成 .env，填上大模型 API Key、数据库密码等。
敲下那一条启动命令，终端里三段日志滚动，分别是三个服务在启动。
全部就绪后，浏览器打开前端地址，看到你熟悉的 AI Todo 界面。
你添加任务、删除任务、让 AI 帮你拆解「下周办一场 50 人沙龙」——全都正常。
刷新页面，任务还在。

如何验收结果是否正确

对照你写的验收标准逐条打勾，这几条尤其关键：

一条命令后，三个服务都起来了吗？
前端能正常增删改吗？
AI 功能可用吗？
刷新后数据还在吗（数据真的落到数据库了）？

四条全绿，意味着你已经能在任何一台装了 Docker 的电脑上，用一条命令拉起整套 AI Todo。这就是集装箱 + 总谱的组合威力。

如果结果不对，怎么反馈给 AI

最常见的两类问题：某个服务没起来、或前端连不上后端。照实描述：

我执行了 docker compose up，前端和数据库起来了，但后端一直在报错重启。
后端的日志是这段（原文粘贴）：
<把日志粘在这里>
另外我在前端点“添加任务”没有反应，怀疑是前端没连上后端。
请帮我定位问题，是环境变量没配对、还是服务之间的地址写错了，修好后告诉我怎么重新启动。

本章小结

一条命令，整套应用拔地而起。你已经把 AI Todo 变成了「随处可一键启动」的完整系统。到这里，它其实已经具备了搬到任何机器上运行的能力——下一章，我们就把它真正搬上公网。

59. 部署到云服务器

这一章要解决什么问题

前面的一键启动，还是在你自己电脑上跑。这一章要动真格：把整套应用搬到一台公网服务器上，让你用手机流量、在任何地方都能访问到它。

这是什么：租一台一直开着的电脑

「云服务器」你可以理解成：你在某个机房里租了一台电脑，它 24 小时开机、有公网地址、你能远程操作它。 云厂商很多（腾讯云、阿里云、AWS 等），但对我们来说，选哪家不影响方法——步骤都是通用的这四步：

1. 租一台云服务器      ← 拿到它的公网 IP、登录方式
2. 在服务器上装 Docker  ← 让它具备「跑集装箱」的能力
3. 把项目传上去         ← 代码搬到服务器
4. 用 Compose 一键启动  ← 和上一章一模一样的那条命令

看出来了吗？第 4 步和你上一章做的完全一样。这正是 Docker 的好处：本地怎么跑，服务器就怎么跑，方法不变，只是换了台机器。

为什么现在需要它

因为你自己的电脑不适合当「服务器」——你要关机、要睡觉、家里网络也没有固定的公网地址。想让别人随时能访问，就需要一台一直醒着、且公网可达的机器。租一台云服务器，就是最省事的办法。

在 AI Todo 里怎么用

我们让 AI 帮你把这四步的具体命令和脚本都生成出来：怎么远程登录服务器、怎么在服务器上装 Docker、怎么把项目传上去（或从 Git 仓库拉下来）、怎么在服务器上填好 .env 并启动。你负责按步骤执行，并最终用手机验收。

⚠️ 把项目传上服务器时，千万别把 .env 一起传上去后又提交回公开仓库，也别把真实的 API Key、数据库密码写进任何会被公开的文件。敏感信息只应该待在服务器的 .env 里，或用云厂商的密钥管理服务保管。这一点，宁可啰嗦十遍。

让 AI 执行的小任务

任务目标：
把我的 AI Todo 部署到一台云服务器上，让我能用公网 IP 访问它。

当前状态：
- 我本地已经能用 docker compose 一键启动整套应用（前端+后端+数据库）。
- 我已经租了一台 Linux 云服务器，拿到了公网 IP 和登录账号密码（或密钥）。
- 我不懂服务器操作，请把每一步的命令都写清楚，我照着敲。

限制条件：
- 不要绑定某一家云厂商的特有工具，用通用的 Linux + Docker 步骤。
- 敏感信息（API Key、数据库密码）只在服务器上的 .env 里配置，
  绝不写进会被提交到仓库的文件。
- 如果服务器需要开放某个端口才能被外网访问，请明确告诉我要开哪个端口。

期望结果：
1. 一份分步骤的部署说明：登录服务器 → 装 Docker → 传项目 → 配 .env → 启动。
2. 每一步都有可以直接复制执行的命令。
3. 告诉我启动成功后，用什么地址（公网 IP + 端口）能访问到应用。

验收标准：
1. 我按步骤在服务器上装好了 Docker。
2. 项目成功传到服务器，并用一条 compose 命令启动了整套应用。
3. 我在自己电脑的浏览器，用「公网IP:端口」能打开应用。
4. 最关键：我用手机（关掉 WiFi、用流量）也能打开这个地址并正常使用。

运行后应该看到什么结果

你远程登录进那台云服务器（一个和平时终端很像的黑框）。
按 AI 给的命令，服务器装好 Docker、收到你的项目、填好 .env。
敲下那条熟悉的 compose 启动命令，三个服务在云端跑起来。
你在电脑浏览器输入 http://公网IP:端口，AI Todo 出现了。
拿出手机，关掉 WiFi 用流量，输入同一个地址——也能打开、也能用。

如何验收结果是否正确

服务器上 Docker 装好了吗？
整套应用在服务器上启动成功了吗？
电脑浏览器用公网 IP 能访问吗？
手机用流量能访问吗（这一条最能证明它真在公网上了）？

💡 手机用流量能打开的那一刻，意义重大：它证明你的应用已经不在你的电脑里了，而是在公网上任何人都能触达的地方。从「我自己能用」到「别人也能用」，你真正跨过去了。

如果结果不对，怎么反馈给 AI

最常见的坑是「服务器上启动了，但外网就是访问不到」，多半是端口没开放（云服务器一般有防火墙 / 安全组）：

我在云服务器上用 docker compose 成功启动了应用，服务器本机也能访问，
但我在自己电脑和手机上用「公网IP:端口」都打不开。
我用的是 XX 云服务器。请判断是不是防火墙 / 安全组没放行端口，
告诉我具体要开放哪个端口、大致在哪里设置，让外网能访问到。

本章小结

部署到云服务器 = 租机器 → 装 Docker → 传项目 → 一键启动，方法和本地几乎一样。当你的手机用流量也能打开应用，你的 AI Todo 就正式上了公网。但现在的地址还是一串难记的 IP，而且没加密——下一章我们给它起个好名字、加把安全锁。

60. 域名、HTTPS 和日志

这一章要解决什么问题

上一章你的应用能访问了，但地址是 http://123.45.67.89:8000 这种没人记得住、还不安全的形式。这一章办三件让它变「正经」的事：给它起个好记的名字（域名）、加把安全的锁（HTTPS）、装个行车记录仪（日志）。

这是什么：三个生活化的比喻

域名：给你的应用起个好记的名字，比如 mytodo.com。以后别人不用背那串 IP，直接输名字就能到——就像你记「肯德基」而不用记它的门牌坐标。
HTTPS：给访问加一把安全的小锁。有了它，浏览器地址栏会出现一个小锁图标，用户和你的应用之间传的数据是加密的，别人偷看不到——尤其重要，因为你的应用里有大模型交互、有用户数据。
日志：应用的行车记录仪。平时默默记录「谁来过、发生了什么、哪里出过错」。一旦线上出问题，日志就是你（和 AI）排查的第一手线索。

为什么现在需要它

没有域名，你没法把应用体面地分享给别人（谁会去输一串 IP）。
没有 HTTPS，现代浏览器会给你的站点标一个「不安全」，用户一看就没了信任，有些功能浏览器甚至直接不让用。
没有日志，线上一旦出问题，你就是两眼一抹黑——不知道错在哪、错在何时。日志是上线后你能睡安稳觉的底气。

在 AI Todo 里怎么用

这三件事都交给 AI 配置。大致是：你先去域名服务商买一个域名、把它解析到你服务器的公网 IP；然后让 AI 帮你在服务器上配好 HTTPS（现在有免费自动签发证书的成熟方案，AI 会用它）；再让 AI 确保三个服务的日志都能方便地查看。你负责最后验收：域名能打开、地址栏有小锁、出问题时能翻出日志。

让 AI 执行的小任务

任务目标：
给我已经部署在云服务器上的 AI Todo 配好域名、HTTPS 和日志查看方式。

当前状态：
- 应用已经能用「公网IP:端口」访问。
- 我已经买好一个域名，并把它解析到了服务器的公网 IP。
- 我不懂 HTTPS 证书，也不知道怎么看日志。

限制条件：
- HTTPS 证书请用免费、能自动续期的方案，不要让我手动每隔几个月去续。
- 敏感信息依然全部走环境变量，别写进任何会公开的文件。

期望结果：
1. 配好之后，我能用「https://我的域名」直接访问应用。
2. 浏览器地址栏出现代表安全的小锁图标。
3. 你告诉我一条命令，能查看前端 / 后端 / 数据库各自的运行日志。

验收标准：
1. 在浏览器输入「https://我的域名」能正常打开 AI Todo。
2. 地址栏有小锁，点开显示连接是安全的。
3. 我故意制造一个小问题（比如填错 API Key）后，能通过你给的命令在日志里
   看到对应的报错信息，从而定位问题。

运行后应该看到什么结果

浏览器输入 https://你的域名，AI Todo 正常打开。
地址栏左边有个小锁，点开写着「连接是安全的」。
AI 给你一条查日志的命令（通常是 docker compose logs），你敲下去，能看到三个服务各自的运行记录滚出来。

如何验收结果是否正确

用域名（而不是 IP）能打开应用吗？
是 https 开头、地址栏有小锁吗？
需要排查问题时，你能看到日志吗？

可以做个小演习：故意把 .env 里的 API Key 改错，让 AI 功能失败，然后用查日志的命令把那条报错找出来。能自己从日志里定位到问题，你就真正具备了「线上运维」最基础也最重要的一项能力。

如果结果不对，怎么反馈给 AI

比如域名打不开，或者小锁没出现（证书没配好）：

我按步骤配置后，用 https://我的域名 打不开，浏览器提示「不安全」或证书错误。
我的域名是 XXX，已经解析到服务器 IP。
请帮我检查是域名解析没生效、还是 HTTPS 证书没配好，
给我可以在服务器上执行的检查和修复命令。

本章小结

域名让应用有了好记的名字，HTTPS 给它加了把安全锁，日志则是出问题时的行车记录仪。这三样配齐，你的 AI Todo 就从「能访问」升级成了「像模像样、可以放心分享」的线上应用。

61. 部署结果验收

这一章要解决什么问题

这一部分做了很多事：打包、Compose、上云、域名、HTTPS、日志。这一章把它们收成一份完整的「部署验收清单」——像前面前端验收清单那样，让你能稳定地判断「我这次到底算不算真正部署成功了」。

这是什么

一份可以随身带走、以后每次上线都能对照的检查表。它把「部署成功」拆成一条条你看得懂、能亲手验的具体标准。

部署验收通用清单

跑得起来吗（启动）

在服务器上用一条 compose 命令，整套应用能成功启动？
前端、后端、数据库三个服务都在正常运行（没有反复重启 / 报错）？

打得开吗（访问）

用域名 + https 能打开应用，地址栏有小锁？
前端界面正常显示，不空白、不报错？

连得通吗（前后端 + 数据库）

前端能正常调用后端（添加、删除、标记完成都有反应）？
添加数据后刷新页面还在，说明数据真的存进了数据库？
关掉应用再重新启动，之前的数据依然还在（数据没随容器消失）？

别人也能用吗（换设备 / 换网络）

用另一台设备（别人的电脑、你的手机）能打开并正常使用？
用手机流量（不连你家 WiFi）也能访问？

AI 在线上还灵吗（核心功能）

让 AI 拆解一个任务，线上环境里能正常返回结果？
AI 的总结 / 分类 / 优先级判断等功能，线上都正常？

安全吗（这条最容易被忽略，但最要命）

API Key、数据库密码等敏感信息，全部通过环境变量注入，代码里没有写死？
.env 已经被 .gitignore 忽略，没有被提交到公开仓库？
翻一遍你推到公开仓库的代码，确认里面搜不到任何真实的 Key 或密码？

哪一条最能代表「真正成功」

💡 如果只能留一条，那就是——换一台设备、换一个网络，别人也能打开并正常使用。 在你自己电脑上跑通，只能算「我能用」；只有当一个和你毫无关系的设备也能访问，才叫「别人也能用」，才是部署这件事真正的目标。这，正是我们这一整部分从第一章就在铺垫的那句话的兑现：从「我自己能用」到「别人也能用」。

⚠️ 安全那一组，请务必逐条亲手核对，尤其是最后一条——去你的公开仓库里搜一遍 Key 和密码。上线后敏感信息泄露，是初学者最常见、后果也最严重的事故。这道判断题，值得你多花五分钟。

如果验收没全过，怎么反馈给 AI

哪一条没打勾，就针对哪一条去问 AI，把清单里的原话当作需求描述：

我在对照部署验收清单，其他都过了，但有一条没过：
换成手机用流量访问时打不开，用电脑连着家里 WiFi 却可以。
请帮我判断原因（是不是端口 / 防火墙 / 域名解析的问题），并给我修复步骤。

本章小结

部署验收 = 跑得起来 + 打得开 + 连得通 + 别人也能用 + AI 还灵 + 足够安全。把这份清单收进口袋，以后每次上线都拿它对照。记住那条最硬的标准：换台设备、换个网络也能用，才算真的部署成功。

这一部分的收尾

值得停下来庆祝一下——你的 AI Todo 真正上线了。 现在，地球上任何一个人，只要打开你的域名，就能用上你亲手（指挥 AI）做出来的这个会拆解任务的智能助手。

回顾你在这一部分学会的事：

✅ 理解了部署就是「从我自己能用，到别人也能用」；
✅ 用 Docker 把应用打包成集装箱，根治「换台机器跑不起来」；
✅ 用 Docker Compose 一份总谱、一条命令，拉起前端 + 后端 + 数据库；
✅ 把整套应用部署到云服务器，用手机流量都能访问；
✅ 配好了域名、HTTPS 和日志，让它安全、好记、可排查；
✅ 拿到了一份可复用的部署验收清单，并守住了敏感信息不泄露的底线。

更重要的是，这一路你依然在做同一件事：想清楚要什么、把任务讲给 AI、一条条验收结果。哪怕是听起来最「运维」的部署，你也没有去背命令、抠原理，而是靠「选择题 + 判断题」把它拿下了。

你的产品已经完整、上线、能被全世界访问。接下来，我们把整段旅程复个盘，再聊聊它还能往哪些方向长大。第十一部分：复盘与扩展，我们收尾，也远望。

最后更新于 2026-07-08

第九部分 · 工程化升级第十一部分 · 复盘与扩展