第五部分 · 加入后端
上一部分我们让 Todo 页面「活」了过来——能添加、能删除、能标记完成。但它有个藏得很深的毛病：所有任务只存在浏览器的内存里，一刷新就全没了。这一部分我们请出「后端」，让它来当那个真正靠谱的「保管员」。
关于这一部分怎么用
这一部分我们会第一次听到几个新词：后端、API、Flask。别紧张，我们的策略和前面一样——先用生活里的东西把概念讲通，再让 AI 把它做出来，最后你负责验收。
- 第 23~25 章：只讲概念，一行代码都不用敲。把「后端是什么、API 是什么、Flask 是什么」这三件事想通。
- 第 26 章：让 AI 用 Flask 建一个真正的后端。
- 第 27 章：改造前端，让它去调用后端。
- 第 28 章：把前后端连起来，做一次完整的联调验收。
⚠️ 提前打个预防针：这一部分我们还不做数据库。后端会先把任务存在自己的「内存」里。所以你会发现一个新问题——后端一重启，数据又没了。这不是 bug，是我们故意留的一个坑，它正是下一部分「加入数据库」的引子。
23. 后端是什么
这一章要解决什么问题
到现在为止，我们做的所有东西都在浏览器里——页面、按钮、列表，全是你「看得见」的部分。这一章要告诉你，一个真正的应用，还有一大半是你看不见的，那部分叫「后端」。
这是什么：前台与后厨
想象你走进一家餐厅。
- 前端，就是你能看到的一切：菜单、餐桌、前台的服务员。它负责「和你打交道」——让你点菜、给你上菜、把菜摆得好看。
- 后端，是你看不到的后厨：切菜、炒菜、备料、把食材存在冰箱里。它负责「真正把事情办了」，然后把成品交给前台端出来。
我们前面几部分做的 Todo 页面，全是「前台」。你输入一件事、点添加、它出现在列表上——服务员很热情，菜单很漂亮。但问题是：这家餐厅没有后厨，也没有冰箱。你点的菜（任务）只是暂时写在服务员手上的小纸条上，客人一走（页面一刷新），纸条就扔了。
后端，就是我们要给这家餐厅补上的后厨 + 冰箱。
为什么现在需要它
上一部分结尾那个让你不满意的地方，根源就在这里：前端天生不擅长「长期保管数据」。浏览器的内存就像服务员的短期记忆，转身就忘。
要让任务「刷新也不丢、换台电脑也还在」，就必须有一个专门负责保管和处理数据的地方——那就是后端。它像后厨一样待在「厨房」里（一台一直开着的服务器上），安安静静地帮你把所有任务收好、管好。
💡 这里有一道你已经会做的判断题：怎么判断一个应用「有没有真正的后端」？很简单——刷新一下，数据还在不在。在，说明有人在后面帮你保管；不在，说明数据只是暂存在前台。这一条，我们这一部分结束时会反复用到。
本章小结
前端是餐厅前台（看得见、管接待），后端是后厨加冰箱（看不见、管处理和保管）。我们的 Todo 现在只有前台，这一部分就是去把后厨建起来。
24. API 是什么
这一章要解决什么问题
有了前台和后厨，马上冒出一个新问题：它俩隔着一堵墙，怎么沟通？ 服务员不能冲进后厨自己炒菜，厨师也不会跑到餐桌前问你要什么。这一章讲清楚它们之间的「沟通约定」——API。
这是什么：前台和后厨之间的点餐单
餐厅里，前台和后厨靠一样东西协作：点餐单，以及那个递单子、端盘子的服务窗口。
- 服务员把你的需求写成一张标准格式的单子：「一份宫保鸡丁」。
- 从窗口递进去。
- 后厨照单做好，再从窗口把成品端出来。
这套「用固定格式的单子隔窗口沟通」的约定，就是 API（应用程序接口）。
放到我们的 Todo 项目里，前端（前台）和后端（后厨）之间也需要这么几张「标准单子」：
- 一张「把所有任务给我看看」的单子。
- 一张「加一条新任务」的单子。
- 一张「删掉某条任务」的单子。
- 一张「把某条任务标记成完成」的单子。
前端要做什么，就递对应的单子进去；后端照单办事，再把结果递出来。API 就是这套双方都认的「单子格式」。
为什么现在需要它
因为前后端是两个分开的东西（甚至可能跑在两台不同的电脑上），它们必须约定好「怎么说话」，否则就是鸡同鸭讲。API 就是这份约定：前端只要按格式递单子，就不用管后厨里到底怎么炒的；后端只要按格式返回结果，也不用管前台长什么样。
💡 这道选择题 AI 会帮你想，但你要能看懂结果：一个功能可以设计成一张单子，也可以拆成好几张。比如「获取任务、新增任务、删除任务」通常是三张不同的单子（三个不同的接口地址）。你不用自己设计这些，但验收时你要能对上号——「我让 AI 做了增删改查四件事，那应该有对应的几个接口」。
你现在不需要去深究 API 背后的 HTTP、请求方法这些技术细节。记住一句话就够了：API 是前端和后端之间递单子的约定。够用了。
本章小结
API 是前台和后厨之间的「点餐单 + 服务窗口」——一套双方都认的沟通约定。前端递单子，后端照单办事再返回结果。细节不用懂，知道它是「前后端说话的规矩」就行。
25. Flask 是什么
这一章要解决什么问题
后端和 API 的道理讲通了，但「后厨」总得用真材实料搭起来。这一章介绍我们用来搭后端的工具——Flask，并说清楚我们为什么现在选它。
这是什么
Flask 是一个用 Python 语言写后端的工具。你可以把它理解成一套**「后厨搭建套件」**：它帮你把开一个后厨、支好服务窗口、接收单子、返回结果这些琐事都准备好，你（其实是 AI）只要往里面填「收到这张单子该做什么」就行。
用 Flask，我们就能很快搭出一个能收单子、能回结果的后端服务——也就是上一章说的那些「递任务单」的 API。
为什么现在需要它（而不是别的）
后端工具其实有很多，Python 里除了 Flask，还有一个很流行的叫 FastAPI。那我们为什么先用 Flask？
💡 这是一道我替你做主的选择题：入门阶段，我们选 Flask，因为它最简单、最好懂。它的概念少、写出来的东西直观，特别适合第一次接触后端的人建立感觉。FastAPI 更强大、更专业，但也更「重」，概念更多。等我们的项目后面变复杂、需要更专业的能力时，课程会带你升级到 FastAPI。先用简单的把事情跑通，再在需要时升级——这本身就是做产品的正确顺序，和我们做前端时「先简单清晰、再精雕细琢」是同一个道理。
所以这一部分你只要记住：Flask = 我们入门用的、最简单的后端搭建工具。 它不是终点，是一个恰到好处的起点。
在我们的项目里怎么用
接下来我们会让 Claude Code / Codex 用 Flask，帮我们搭一个 Todo 后端。它会：
- 开一个后端服务（后厨开张）。
- 提供几个 API 接口（支好几个递单窗口：获取、新增、删除、标记完成）。
- 先把所有任务存在内存里的一个列表变量里（相当于先用一块小白板记账，还没上冰箱）。
你不用会写 Python，也不用看懂 Flask 的代码。你要验收的还是结果：这个后端能不能启动、能不能按单子返回任务数据。
本章小结
Flask 是我们入门用的后端搭建套件，用 Python 写，胜在简单好懂。先用它把后端跑通，以后项目复杂了再升级到更专业的 FastAPI。
26. 创建 Todo API
这一章要解决什么问题
概念铺垫完了，这一章正式动手：让 AI 用 Flask 建出一个真正能用的 Todo 后端——能获取任务列表、新增任务、删除任务、更新完成状态。这是我们第一个「看不见但真实存在」的成果。
这是什么
我们要建的，是上一章说的那个「后厨」：一个 Flask 后端服务，对外提供四张「单子」（四个 API 接口）。它先把任务存在内存的一个列表里，能收单、能回数据。
让 Claude Code / Codex 执行的小任务
在你的 Todo 项目里启动 AI，把下面这个任务提示词发给它：
任务目标：
用 Flask 帮我做一个 Todo 后端 API 服务，给现有的前端提供任务数据。
当前状态：
我已经有一个用 Vue 做的 Todo 前端，任务目前只存在浏览器内存里，
刷新就会丢。现在我想加一个后端来保管这些任务。我完全没有 Python 基础。
限制条件：
1. 后端用 Flask，越简单越好，方便我入门理解。
2. 这次先不要用数据库，任务先存在内存里的一个列表变量里即可。
3. 请提供以下四个接口：获取任务列表、新增一条任务、删除一条任务、
更新某条任务的完成状态。
4. 一开始列表里先放两三条示例任务，方便我一打开就能看到数据。
期望结果：
1. 我能用一条命令把这个后端启动起来。
2. 启动后，我用浏览器访问「获取任务列表」的接口地址，
能看到返回的示例任务数据。
验收标准：
1. 你明确告诉我：用什么命令启动后端、启动后它跑在哪个地址（比如
http://localhost:5000）、以及「获取任务列表」的完整接口地址是什么。
2. 我在浏览器打开那个地址，能看到任务数据。
3. 过程中没有报错。💡 注意这个提示词里，我们把「限制条件」写得很死：用 Flask、先不用数据库、就四个接口、存内存。这就是在做选择题——我们主动帮 AI 把范围框好，它就不会自作主张给你上一堆你还看不懂的东西。框得越清楚，验收越轻松。
运行后应该看到什么结果
- AI 会创建一两个 Python 文件（大概率有一个
app.py），可能还会让你先装一下 Flask。 - 它会告诉你一条启动命令，你运行后，终端里会显示后端正在某个地址上运行（通常是
http://localhost:5000，注意这个端口和前端不一样）。 - 你用浏览器打开它给你的「获取任务列表」接口地址，屏幕上会出现一串任务数据。它长得可能像这样（这就是所谓的 JSON，先不用管格式细节，能看懂里面是你的任务就行）：
[
{"id": 1, "title": "买菜", "done": false},
{"id": 2, "title": "写周报", "done": true}
]如何验收结果是否正确
对照你写的验收标准逐条打勾：
- AI 告诉我启动命令和接口地址了吗？
- 后端启动后，终端显示它在某个地址上运行了吗？
- 浏览器打开「获取任务列表」的地址，看到任务数据了吗？
- 全程没有报错？
💡 不懂代码也能验收：你完全不用看懂
app.py里那些 Python。你只要能在浏览器里看到那串任务数据，就说明后厨开张了、单子递得进去、菜也端得出来。看得见数据 = 后端通了。 这就是判断题。
如果结果不对，怎么反馈给 AI
比如启动就报错，或者浏览器打开地址是一片空白 / 一堆红字：
我按你给的命令启动后端，但出现了问题。终端（或浏览器）里报了下面这段错误（原文粘贴）：
<把报错整段粘在这里>
我期望的是：能启动后端，并在浏览器访问接口地址看到任务数据。
请告诉我原因，并给我可以直接执行的修复方法。本章小结
你有了人生第一个后端 API。它用 Flask 搭成，提供增删改查四个接口，任务先存在内存里。验收方法很朴素——浏览器打开接口地址，看得到任务数据就算通了。
27. 前端调用后端
这一章要解决什么问题
现在你有两样东西：一个存着假数据、刷新就丢的 Vue 前端，和一个真能保管任务的 Flask 后端。但它俩还没连上——前端根本不知道后端的存在。这一章就是牵线搭桥：让前端不再自己存数据，改成去调用后端的 API。
这是什么
「前端调用后端」，就是让前台的服务员开始往后厨递单子。以后：
- 打开页面 → 前端向后端要「任务列表」→ 把后端返回的任务显示出来。
- 你点添加 → 前端递一张「新增任务」的单子给后端。
- 你点删除 / 标记完成 → 前端递对应的单子给后端。
数据的「真身」从此存在后端，前端只负责显示和转达。服务员不再自己记小纸条了，全交给后厨的冰箱。
让 Claude Code / Codex 执行的小任务
任务目标：
改造我现有的 Vue 前端，让它的增删改查都改成调用我刚做好的 Flask 后端 API，
不要再把任务存在浏览器内存里。
当前状态：
1. 我有一个 Vue 前端，目前任务存在浏览器内存里，刷新会丢。
2. 我有一个 Flask 后端，提供了获取列表、新增、删除、更新完成状态四个接口，
跑在 <把你后端的地址填进来，比如 http://localhost:5000>。
限制条件：
1. 只改前端调用数据的方式，页面的样子和布局尽量保持不变。
2. 所有任务数据都以后端为准，前端不要再自己保存。
期望结果：
1. 页面一打开，显示的是从后端获取到的任务列表。
2. 我添加 / 删除 / 标记完成，都会真正通知后端，并且页面同步更新。
验收标准：
1. 前端和后端同时启动后，页面显示的是后端里的任务。
2. 我做的增删改操作，刷新页面后依然存在（因为已经存到后端了）。
3. 过程中没有报错。运行后应该看到什么结果
- AI 会修改你的 Vue 前端代码，把原来「在内存里增删」的逻辑，换成「向后端接口发请求」。
- 它会提醒你：现在要同时开着两个服务——后端（Flask）和前端（Vue）各自在一个终端里跑着。
- 页面打开后，看起来和之前几乎一样，但数据的来源已经悄悄换成后端了。
⚠️ 可能会撞上一个叫「跨域 / CORS」的报错。你按
F12打开控制台，可能看到一段红字里提到CORS或跨域。这是浏览器出于安全，对「前端找另一个地址的后端要数据」设的一道关卡。你完全不用懂它的原理——遇到了，就把报错整段发给 AI：
前端调用后端时，浏览器控制台报了跨域（CORS）相关的错误，原文如下：
<把报错整段粘在这里>
请帮我在后端配置好，让前端可以正常访问后端接口。AI 通常在后端加几行配置就能解决。这又是一次判断题 + 反馈：你不解决问题本身，你只负责发现它、把它准确地交给 AI。
如何验收结果是否正确
- 前端、后端两个服务都启动了吗？
- 页面显示的是后端里的任务吗？
- 添加 / 删除 / 完成操作，页面有跟着变吗？
- 控制台（
F12）里没有红色报错吗？
如果结果不对，怎么反馈给 AI
除了跨域，最常见的是「页面空白」或「操作没反应」。照实描述即可：
两个服务我都启动了，但页面上一条任务都没显示（之前后端接口是能看到数据的）。
控制台报了这个错：<粘贴>。
请检查前端是不是没正确调用后端接口，并修好它。本章小结
前端从「自己记账」改成了「向后端递单子」，数据真身搬到了后端。记住两件事：前后端要同时跑起来；遇到跨域报错别慌，整段发给 AI 让它配好就行。
28. 前后端联调验收
这一章要解决什么问题
单独看前端 OK、单独看后端也 OK，不代表它俩合起来就 OK。这一章我们做一次完整的联调验收——像餐厅正式开业前的一次「走单演练」，把前台点单、后厨出菜、来回传递整条链路跑一遍。
这是什么：一次完整的走单演练
「联调」就是把前端和后端连在一起，从头到尾走一遍真实操作，确认每一步都对得上。这是你验收「后端这一部分做没做成」的总考试。
前后端联调验收清单
请同时启动前端和后端两个服务，然后照下面这份清单，一条条亲手操作、亲眼确认：
两个服务都在跑吗
- 后端（Flask）在一个终端里运行着，没报错？
- 前端（Vue）在另一个终端里运行着，能在浏览器打开？
加任务，后端真的收到了吗
- 在前端加一条新任务（比如「测试联调」），它出现在列表里了吗？
- 直接用浏览器打开后端的「获取任务列表」接口地址，这条新任务也在里面吗？（在，就证明前端真的把数据递到后厨了，不是自己演的。）
刷新前端，数据还在吗
- 把前端页面刷新一下，刚才加的任务还在吗？
- （应该在——因为数据现在存在后端，不再是浏览器内存。这正是我们这一部分最想要的效果，也是「有没有真后端」的判断标准。）
删除 / 完成能同步吗
- 在前端删掉一条任务，再刷新，它是不是真的没了？
- 把一条任务标记成完成，刷新后，它还是完成状态吗？
全部打勾，恭喜你——前后端第一次真正协作成功了。你的 Todo 从一个「一刷新就失忆」的页面，变成了一个「有后厨帮你保管数据」的真应用。
💡 这份清单的精髓，还是那三个字：看结果。 你没看一行 Flask 代码、没懂一句 CORS 原理，但靠「加一条 → 去后端确认 → 刷新看还在不在」这套动作，你就能百分之百确定后端到底通没通。能验收，你就掌控了这个项目。
如果结果不对，怎么反馈给 AI
如果某一条对不上，就精确地告诉 AI 是「哪一步」断了：
前后端联调时发现一个问题：我在前端添加了任务，页面上能看到，
但刷新之后就没了；而且我直接访问后端的获取任务列表接口，里面也没有这条新任务。
这说明前端的「新增」可能没有真正提交到后端。请帮我检查并修好，
让新增的任务能真正保存到后端、刷新后依然存在。描述得越具体（在哪一步、看到了什么、期望是什么），AI 修得越快。 这是你和 AI 协作到现在，应该越来越顺手的一项本领。
本章小结
联调验收 = 同时开两个服务 + 走一遍「加 / 删 / 完成 / 刷新」的完整链路，并且到后端接口里去核实数据真的进去了。全部对上，后端这一部分就通关了。
这一部分的收尾
回头看，你在这一部分完成了一次不小的跨越：
- 想通了三个新概念：后端（后厨 + 冰箱）、API（递单子的约定）、Flask（入门用的后端套件）。
- 让 AI 用 Flask 建起了真正的后端 API。
- 把 Vue 前端改成了调用后端，数据真身搬到了后端。
- 用一份联调清单，稳稳验收了整条前后端链路。
最关键的是，你的应用终于有了一个「靠谱的保管员」——刷新前端，任务不再丢了。
但是……还记得我们埋的那个坑吗？现在数据是存在后端的内存里的。你可以现在就亲手验证一下：把后端那个服务关掉再重新启动，然后刷新前端——你会发现，任务又全没了。
⚠️ 内存就像后厨里的一块小白板：营业时记得清清楚楚，可一旦「打烊关灯再开门」（后端重启），白板就被擦干净了。我们缺的，是一个真正的冰箱——关机断电，东西也还在。
这个「重启就丢」的痛点，正是下一步的动力。我们需要给后端配一个能长期保存数据的地方——数据库。
带着这个问题，我们进入 第六部分：加入数据库，给你的 AI Todo 装上那个「关了电也不会忘事」的冰箱。