第六部分 · 加入数据库

上一部分我们给应用装上了 Flask 后端，前后端能好好说话了。但它藏着一个大问题：后端把任务都记在「脑子」里，一重启，全忘光。 这一部分我们要解决这个致命伤——让数据真正「落地保存」，即使关机重启也丢不了。这是应用从「玩具」变成「真实产品」最关键的一步。

29. 数据库是什么

这一章要解决什么问题

先说清楚你现在这个应用最要命的毛病：数据是「临时」的。你添加的任务，只活在后端运行的那一小段时间里。后端一重启，或者电脑一关机，它们就集体消失了。这一章告诉你，为什么需要一个叫「数据库」的东西来根治这个问题。

这是什么

打个比方。现在你的后端就像一个记性很好但一睡就忘的人：你跟他说的事，他当时全记得，能随叫随答；可他一睡觉（重启），醒来就一片空白，昨天的事一件都想不起来。

数据库，就是给他配一个「永久的账本」。 你说的每件事，他都当场抄进账本里。这样哪怕他睡了、忘了、换人了，只要账本还在，翻开一看，所有记录原封不动。

再形象一点：数据库就像一个带格子的储物柜——每件东西都有固定的格子，贴好标签，摆得整整齐齐。断电也好、搬家也好，柜子里的东西一样不少，而且你随时能按标签精准地拿出任何一件。

为什么现在需要它

回想一下你现在的使用体验，问题很直接：

你添加了几个任务，很开心。
后端因为某些原因重启了（改代码、断电、部署）。
你回来一看——列表空了，昨天加的全没了。

一个「刷新页面就丢数据、重启后端就清零」的应用，没人敢真正用它记事。能把数据存住，是一个应用「可被信任」的底线。 数据库就是来兜这个底的。

💡 这里其实是一道判断题：怎么判断「数据到底存住了没有」？标准特别朴素——把后端重启一遍，数据还在，就算存住了；没了，就是没存住。 记住这个「重启大法」，它是本部分从头到尾的验收核心。

本章小结

后端的内存像「一睡就忘的记性」，数据库是「永久的账本 / 带格子的储物柜」。它解决的就是一件事：让数据在刷新、重启、关机之后依然还在。

30. SQLite 是什么

这一章要解决什么问题

知道要用数据库了，但数据库有好多种，初学者又要开始纠结「选哪个」。这一章直接帮你收敛：入门就用 SQLite，并告诉你为什么它是最省心的第一选择。

这是什么

SQLite 是一个极其轻量的数据库。它最大的特点，用一句话就能说清：

一个文件，就是一整个数据库。

不需要你另外安装什么服务、开什么后台程序、配什么账号密码。你的所有任务数据，就安安静静地躺在一个文件里（通常叫 todo.db 之类）。想备份？把这个文件复制走就行。想搬家？把文件拷过去就行。简单到不像个数据库。

你可以把它想成一个随身的小账本：轻便、免安装、拿了就能用，记账完全够使。

为什么入门首选它

💡 又一道选择题，这道我替你选好了：入门用 SQLite。 理由很实在——它零配置、免安装、一个文件搞定。别的数据库（比如后面会提到的 PostgreSQL）功能更强，但要你装服务、起进程、配连接，对初学者是一堆额外的坑。学做产品的第一阶段，我们要的是「尽快让数据能存住」，而不是「一上来就上最专业的家伙」。SQLite 恰好是这个阶段的最优解。

而且你不用担心「用了简单的，以后会不会推倒重来」。SQLite 本身就是正经、可靠、被无数真实应用使用的数据库。它足够你把整个 AI Todo 的功能全部做完。等真到了需要更强数据库的那天（本部分最后一章会讲），换起来也不难——而且那时候你已经不是零基础了。

在我们项目里怎么用

思路很清晰：让 Flask 后端，从「把任务存在内存里」，改成「把任务存进一个 SQLite 文件」。

新增任务 → 写进 SQLite 文件。
展示列表 → 从 SQLite 文件里读出来。
完成 / 删除 → 到 SQLite 文件里改掉。

对你来说，动作还是老样子：写清楚任务提示词，让 AI 去改，然后靠「重启大法」验收。 底层从内存换成文件的这些技术细节，交给 AI，你只管盯着结果。

本章小结

SQLite = 一个文件就是一个数据库，零配置、免安装。它是入门阶段的最优选择，也完全够我们把整个项目做完。下一章，我们就让后端真正开始往这个文件里写数据。

31. 保存 Todo 数据

这一章要解决什么问题

这是本部分的第一场硬仗，也是最有里程碑感的一步：让「新增任务」这个动作，真正把数据写进 SQLite 文件。 做完这一章，你添加的任务就第一次拥有了「不会丢」的能力。

这是什么

之前你点「添加」，任务是被塞进了后端的内存（那个一睡就忘的记性）。现在我们要改成：点「添加」→ 后端把这条任务写进 SQLite 文件。就像从「口头答应」升级成「白纸黑字记进账本」。

让 AI 执行的小任务

在项目里启动 Claude Code / Codex，把下面这个任务提示词发给它。注意：这一步只让它做「保存」这一件事，先别贪心让它把读取、删除一起改了——一次只推进一小步，出了问题才好定位。

任务目标：
把 Flask 后端保存任务的方式，从内存改为存入 SQLite 数据库。

当前状态：
现在后端把 Todo 任务存在内存里（一个列表或变量中），
后端一重启，之前添加的任务就全部丢失了。

限制条件：
入门阶段使用 SQLite，用一个本地文件作为数据库即可，不要引入其他数据库。
这一次只改「新增任务」这一条链路：新增任务时要写入 SQLite。
先不要动查询、删除、完成状态的逻辑，我们下一步再处理。
不要改动前端代码。

期望结果：
调用「新增任务」的接口时，任务会被真正写进 SQLite 数据库文件；
数据库文件如果不存在，就自动创建好。

验收标准：
1. 你告诉我数据库文件叫什么名字、在哪个目录。
2. 我新增一个任务后，这个数据库文件确实存在。
3. 关键：我把后端停掉再重新启动，之前新增的这条任务的数据依然还在数据库里。
4. 过程中没有报错，你告诉我怎么确认「数据确实写进去了」。

运行后应该看到什么结果

AI 会改动后端代码，并告诉你数据库文件叫什么（比如 todo.db）、在哪儿。
你的项目文件夹里，真的多出一个数据库文件。
你新增一个任务后，AI 能带你确认这条数据已经进了库（比如让你再调一次接口、或用它给的方式查看）。

如何验收结果是否正确

这一步的验收，请务必做那个最关键的动作——重启大法：

新增任务后，项目里出现了数据库文件（如 todo.db）？
把后端停掉（关掉再重新 启动），刚才新增的数据还在吗？
全程没有报错？

第 2 条是灵魂。如果重启后数据还在，恭喜你，数据第一次「活过来了」——它不再依赖后端开不开机。 如果重启后又没了，那说明其实还在用内存，没真正写进文件，往下看怎么反馈。

⚠️ 别被「看起来能用」骗了：只是加完任务、还没重启就去看，数据当然在——但这证明不了什么。必须重启后再看，才能真正判断「存住了没有」。这就是这一步判断题的正确姿势。

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

如果重启后数据还是丢了，照实说：

我按你说的新增了任务，也看到了数据库文件。
但我把后端停掉再重新启动后，之前新增的任务又不见了。
这说明数据可能还是存在内存里，没有真正写进 SQLite。
请检查新增任务的逻辑，确保它是写进 SQLite 文件的，
然后再告诉我一次如何验证「重启后数据仍然存在」。

本章小结

你完成了本部分最有分量的一步：新增的任务，第一次被真正写进了数据库文件。验收它的黄金标准就一句话——重启后端，数据还在。

32. 查询 Todo 数据

这一章要解决什么问题

上一章我们把数据「写进去了」，但前端展示的列表，可能还在读老地方（内存）。这一章要让后端从 SQLite 里把任务读出来，返回给前端，让你看到的列表，就是数据库里真实存着的数据。

这是什么

「保存」和「读取」是数据库的两个基本动作，像账本的「记一笔」和「翻一页」。上一章练了「记一笔」，这一章练「翻一页」：前端要显示列表时，后端就去 SQLite 文件里把所有任务捞出来，交给前端展示。

做完这一章，你的应用就形成了一个完整的闭环：写进数据库 → 从数据库读出来显示。

让 AI 执行的小任务

任务目标：
让 Flask 后端从 SQLite 数据库读取任务列表，返回给前端展示。

当前状态：
新增任务已经能写入 SQLite 了（上一步完成的）。
但后端返回给前端的任务列表，可能还是读的内存里的旧数据，不是数据库里的。

限制条件：
继续使用 SQLite，不要引入其他数据库。
这一次只改「查询 / 返回任务列表」这一条链路：列表数据要从 SQLite 里读。
先不要动删除和完成状态的逻辑。
不要改动前端页面的样式和结构。

期望结果：
前端加载或刷新时，看到的任务列表，就是 SQLite 数据库里真实存着的所有任务。

验收标准：
1. 前端刷新页面后，能正确显示数据库里已有的任务。
2. 我新增一个任务后刷新，新任务出现在列表里。
3. 关键：我把后端重启，再打开前端，之前的任务列表依然完整显示。
4. 没有报错。

运行后应该看到什么结果

打开或刷新前端，任务列表正常显示——而这些任务，来自数据库文件。
你新增一条、刷新一下，它稳稳出现在列表里。
最关键的：重启后端，再刷新前端，列表还是那些任务，一条不少。

如何验收结果是否正确

前端刷新，任务列表能正常显示？
新增任务后刷新，新任务出现在列表里？
重启后端 + 刷新前端，列表依然完整？
没有报错？

到这一步，你可以做一个特别有成就感的小实验：加几个任务 → 关掉后端 → 重新启动后端 → 刷新前端。如果那几个任务原封不动地回来了——你的数据，是真的存住了。

💡 这是本部分核心判断题的完整形态：不只是「加完能看到」，而是「重启后还能看到」。前者只能证明程序当下在跑，后者才能证明数据真的落进了硬盘。以后判断任何「持久化」功能，都用这一招。

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

前端能显示任务，新增后刷新也能看到。
但我把后端重启后再刷新前端，列表就空了 /（或）显示的还是旧的示例数据。
这说明列表可能不是从 SQLite 读的。
请检查返回任务列表的逻辑，确保它是从 SQLite 数据库里查询的，
然后告诉我怎么验证「重启后端后列表仍然完整」。

本章小结

写进去（上一章）+ 读出来（这一章）= 一个完整的数据闭环。验收依旧靠重启大法：重启后端，刷新前端，列表还在，就通关。

33. 修改和删除 Todo 数据

这一章要解决什么问题

现在「加」和「看」都通了数据库，但还差两个高频动作：把任务标记完成、把任务删掉。这一章要让这两个操作也真正落到数据库上，而不是改改内存、重启就打回原形。

这是什么

到目前为止，数据库的四个基本动作（俗称「增、查、改、删」）你已经打通了前两个：

增（新增任务）✅ 第 31 章
查（读取列表）✅ 第 32 章
改（切换完成状态）← 这一章
删（删除任务）← 这一章

这一章把剩下的「改」和「删」也接到 SQLite 上。做完，你的应用对数据的四种基本操作就全部「持久化」了——任何改动都是白纸黑字记进账本，不再是过眼云烟。

让 AI 执行的小任务

任务目标：
让「切换完成状态」和「删除任务」两个操作，也真正修改 SQLite 数据库。

当前状态：
新增和查询任务都已经走 SQLite 了。
但「标记完成 / 取消完成」和「删除任务」可能还只改了内存，
后端一重启，完成状态和删除操作就失效、回到从前。

限制条件：
继续使用 SQLite。
这一次只改两条链路：切换完成状态、删除任务。
不要改动前端页面的结构和样式。

期望结果：
把任务标记为完成 / 取消完成时，这个状态被写进 SQLite；
删除任务时，这条数据从 SQLite 中真正被删掉。

验收标准：
1. 我把某个任务标记为完成，刷新前端后它仍然是完成状态。
2. 我删除某个任务，刷新前端后它不再出现。
3. 关键：我把后端重启，被删除的任务依然是删掉的，
   被标记完成的任务依然是完成状态。
4. 没有报错。

运行后应该看到什么结果

你点某个任务「完成」，它变成完成样式；刷新，还是完成的。
你删掉一个任务，它从列表消失；刷新，也不会再冒出来。
重启后端后：删掉的还是删掉的，完成的还是完成的——所有改动都稳稳地留住了。

如何验收结果是否正确

标记完成 → 刷新 → 仍是完成状态？
删除任务 → 刷新 → 不再出现？
重启后端 → 删掉的依然没了、完成的依然完成？
没有报错？

⚠️ 删除功能，务必用重启大法验一遍：有一种很隐蔽的假象——删除只是把它从「当前内存的列表」里拿掉了，数据库里其实还留着。这时你重启后端，被「删掉」的任务会诈尸复活。所以别只看「刷新后没了」，一定要重启后端再确认它是真的没了。

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

删除任务后刷新，确实看不到了。
但我把后端重启后，被我删掉的任务又出现在列表里了。
这说明删除可能只改了内存，没有真正从 SQLite 里删掉。
请检查删除任务的逻辑，确保它把数据从 SQLite 数据库中真正删除，
完成状态的切换也请确认是写进了数据库。
然后告诉我怎么验证「重启后端后，删除和完成状态都保持不变」。

本章小结

增、查、改、删，四个基本动作现在全部落到了 SQLite 上。你的应用对数据的每一次改动，都是真实、持久、重启不丢的。删除尤其要小心「诈尸」——重启后再确认一次，才算数。

34. 数据保存结果验收

这一章要解决什么问题

前面三章我们分头做了「增查改删」，这一章把它们串成一次完整的、正式的数据验收。给你一份可以随身带走的「数据验收清单」，让你能一次性、系统地确认：这个应用的数据，是真的存住了。

先停下来，感受一下这个里程碑

在跑清单之前，请先意识到一件事：你正在跨过整门课里最重要的一道坎。

之前的应用，无论页面多好看、交互多流畅，本质上都是个「玩具」——它记不住任何东西，关掉就归零。而从这一部分开始，它能真正地记事了。你今天加的任务，明天打开还在；你标记完成的进度，重启也不丢。

这，就是一个应用从「演示品」变成「能用的产品」的分水岭。「数据能不能存住」，是普通人判断一个应用够不够真实的最朴素、也最硬的标准。 你现在做到了。

一份完整的数据验收清单

把下面这套流程完整走一遍。它不是抽查，是一次「体检」——每一条都亲手试，别脑补：

第一关：基本存取

新增几个任务，它们都出现在列表里？
关掉前端页面、重新打开（刷新），任务还在？

第二关：重启大法（本部分的灵魂）

把后端彻底停掉，再重新启动，之前的任务列表完整回来了？
重启后新增的任务和之前的任务，都能正常显示、不会互相覆盖？

第三关：删除是真的删了吗

删除一个任务，刷新后它消失了？
重启后端后，被删的任务没有「诈尸」复活？

第四关：完成状态存住了吗

标记某个任务完成，刷新后仍是完成状态？
重启后端后，完成状态依然保持，没有被打回未完成？

第五关：多操作混合

加两个、删一个、完成一个，然后重启后端 —— 最终状态和你操作完时完全一致？

💡 这一章是把本部分的判断题「集大成」了：单个功能能过，不代表整体没问题。真正的验收，是把「增删改」混在一起做，再用重启大法一次性检验最终状态对不对。能稳定跑通这份清单，你就有底气说：我的应用，数据是可信的。

如果某一关没过，怎么反馈给 AI

哪一关没过，就精准地把那一关的现象反馈给 AI，别笼统地说「有问题」。例如：

我在做数据验收，大部分都正常，但有一关没过：
我先新增了 3 个任务，删除其中 1 个，再把 1 个标记为完成，
然后重启后端。重启后我发现：被删除的那个任务又出现了，
但完成状态是对的。
请检查删除逻辑是否真正写入了 SQLite，
修好后告诉我怎么重新验证这个「混合操作 + 重启」的场景。

本章小结

一份五关验收清单，一个灵魂动作——重启大法。跑通它，代表你的应用完成了从「玩具」到「真实产品」最关键的一跃：数据，终于存住了。

35. PostgreSQL 是什么

这一章要解决什么问题

数据存住了，你可能会听到一个词：PostgreSQL，一个「更专业」的数据库。这一章要回答两个问题：它是什么？以及一个更重要的、属于你自己的选择题——现在这个阶段，我该不该从 SQLite 换成它？（提前剧透：不该，先别换。）

这是什么

PostgreSQL（常简称 PG）是业界最主流的「正式级」数据库之一。用一个比喻讲清它和 SQLite 的区别：

SQLite，像你家里的一个记事本 / 小账本：随身、免安装、自己记事完全够用。一个人用，顺手极了。
PostgreSQL，像一座银行级的数据中心：有专门的机房、保安、流程，能扛住成千上万人同时存取，又快又稳又安全。

区别不在于「谁更高级」，而在于使用场景。你一个人记待办，用记事本刚刚好；可要是全城人都来你这儿存钱取钱，还想同时办理不出错，那就得上银行级的数据中心了。

什么时候该从 SQLite 换到 PostgreSQL

一句话：当「很多人要同时、高频地读写你的数据」时。 具体的信号是：

你的应用要正式上线，给很多人用了。
并发变高了——很多人在同一时刻加任务、改任务。
数据量越来越大，或者对可靠性、备份、安全有了更严肃的要求。

在这些场景下，SQLite（家用记事本）会开始吃力，而 PostgreSQL（数据中心）正是为此而生。

一道该你自己拿主意的选择题

💡 现在这个阶段，该不该换成 PostgreSQL？答案是：还不需要。 你的 AI Todo 现在是一个自己学习、自己使用的项目，一个人用，SQLite 绰绰有余。在真正需要之前就急着换上「银行级数据中心」，是典型的「过早优化」——花大力气解决一个你现在根本没有的问题，反而拖慢真正要紧的事：把功能做完、做好。
正确的节奏是：先用 SQLite 把整个应用（包括后面的 AI 能力）都做出来、跑起来；等到真要正式上线、真有很多人用了，再来考虑换 PostgreSQL。 到那时，换数据库同样可以交给 AI，而你也早已不是零基础的你了。

学会「按阶段做选择」，比学会任何一个数据库都值钱。 什么阶段用什么工具，不追新、不贪多，这是产品负责人最重要的判断力之一。

本章小结

PostgreSQL 是银行级的数据中心，适合「很多人同时高频读写、要正式上线」的场景。而你现在还在打磨阶段，先用 SQLite 把功能做完，别过早优化——这道选择题的答案，是「等真需要了再换」。

这一部分的收尾

停下来看看你跨过的这道坎——它比看起来重要得多：

✅ 你的应用有了自己的数据库（一个 SQLite 文件）。
✅ 新增的任务会真正写进数据库。
✅ 列表从数据库读取，刷新、重启都完整。
✅ 完成状态、删除操作都真实持久，重启不丢、删除不诈尸。
✅ 你手里有一份「五关数据验收清单」，能稳定判断「数据到底存没存住」。
✅ 你想明白了一件事：SQLite 够用就先别急着上 PostgreSQL——按阶段选工具，别过早优化。

最重要的是那句话：数据，终于存住了。 你的 AI Todo 从一个「关掉就归零的演示品」，正式变成了一个「能记住事情的真实应用」。这是整门课里含金量最高的里程碑之一。

现在，应用能存事了。接下来，我们让它变聪明。第七部分：加入 AI 能力，我们请出这门课真正的主角——让这个待办清单，长出一个会帮你拆解任务、分类、判断优先级的「AI 大脑」。

最后更新于 2026-07-08

第五部分 · 加入后端第七部分 · 加入 AI 能力