数据库

Database

也常被叫作：数据库数据存储存数据的地方DB

后端与数据通常止于「运行时」约 2 分钟读完

你可能会这么说

「网站背后真正存数据的地方：注册的账号、发的帖子都存在这里，不在网页文件里。」

数据库 Database

按结构长期存放、可查可改可删的数据系统；网页是看板，数据库才是仓库。

你看到的网页是货架上的陈列，数据库是后面的仓库。关掉页面、甚至删掉整个网页文件，仓库里的货还在——下次打开页面，又从仓库把货搬出来。所以「关掉页面数据会不会丢」的答案取决于数据存在哪：存数据库里就不丢；存在页面代码里（写死的假数据）或浏览器本地存储里，换台设备或清一下缓存就没了。

最常见的是关系型数据库（MySQL、PostgreSQL、SQLite）：数据存在「表」里，表像 Excel——列是字段（用户名、邮箱、注册时间），行是一条条记录（每个用户一行）。表之间还能用共同字段关联：订单表记着 user_id 指向用户表。另一种常见的是文档型（MongoDB），直接存 JSON 文档，结构更灵活。选哪种不是玄学：要关联查询、结构固定选关系型；结构多变、以文档为整体存取选文档型。SQLite 特殊在它就是一个文件，不用装服务器，适合练手和本地小项目。

跟 AI 协作要守规矩，因为数据库是「有状态」的：改错了，数据真就坏了，而且删掉或覆盖的数据很难恢复，除非之前有备份——回滚代码救不了被覆盖的数据。所以涉及数据库的改动守三条：动手前先备份（导出）；先在测试库或本地跑，别直接在生产库执行；改数据（删、更新）先看清会命中哪些行。AI 为了演示方便有时用「内存库」或临时文件，重启就清空——验收时必须问清数据存在哪。

长什么样真实可交互，不是截图

users 表（关系型数据库里的一张表）
id | name | email            | created_at
1  | 阿麦 | mai@example.com  | 2026-08-01
2  | 小麦 | xiao@example.com | 2026-08-10

网页：看板→数据在数据库→改删前先备份

表就是「列（字段）+ 行（记录）」，跟 Excel 一个思路。上面是演示数据，不是真实用户。

拆开看，里面有这几块

1
表 Table
关系型数据库的存储单元：列是字段，行是记录，像一张 Excel 表。
2
字段 Column / Field
一条记录的一个属性，如 name、email，每个字段有类型（文字、数字、时间）。
3
记录 Row / Record
一行就是一条完整数据，比如一个用户的全部信息。
4
主键 Primary Key
唯一标识一条记录的字段（通常是 id），靠它区分「这条」和「那条」。

常见的有哪几种

关系型Relational (SQL)

数据存表里，表之间可关联，用 SQL 操作。最成熟最常见。

用在：用户、订单、内容这些结构固定、要关联查询的数据

文档型Document (NoSQL)

直接存 JSON 文档，不用先定表结构，字段可以随时加。

用在：结构多变、以整份文档为存取单位的数据

文件型 SQLiteSQLite

整个数据库就是一个文件，不用装服务器。

用在：练手、本地小项目、单机应用

容易搞混？这样区分

数据库 ≠ API API

数据库是存数据的地方，API 是取数据的门。前端不直接摸数据库，它走 API；后端在 API 背后才去碰数据库。你看到的是 API，数据库藏在后端更深处。

看 API

数据库 ≠ 浏览器本地存储 localStorage

浏览器本地存储是存在用户自己设备上，只对那一台设备、那一个浏览器有效，清缓存就没了；数据库存在服务器端，换设备换浏览器数据都在。AI 说「数据已保存」时，先问存在哪一边。

看浏览器本地存储

什么时候用得上

用户注册

用户填的账号信息通过 API 存进数据库的 users 表，之后登录时从这张表查。

发布内容

帖子、评论都存在数据库里，页面只是把数据库里的内容读出来展示。

统计

「这个月新增了多少用户」这类问题，本质是数数据库里的行数，不是数页面。

你可以这样跟 AI 说

直接复制下面这段，把【】里的换成你的情况。它比一句「帮我加个 X」多说清楚了：改哪里、不许动啥、做完交什么。

【任务】把 [注册功能] 的数据真正存到数据库里
【范围】只做用户注册这一张表和相关写入逻辑；不做登录、不改已有页面
【目标】用户注册后，数据能写进 [数据库名] 的 users 表，重启服务后数据还在
【边界】不要用内存库、不要用临时文件代替数据库；不要在生产数据库上直接执行未备份的改表操作；不要把密钥、连接密码写进代码
【交付】
  1. 连接的是哪个数据库、哪个库名：本地文件库给文件路径，远程库给地址和库名
  2. 注册一个新账号后，执行一条查询，把这张表里这条记录的原样输出贴给我（id、各字段、时间）
  3. 重启服务后再查一次，证明数据还在
  4. 告诉我数据存在服务器哪个位置、有没有备份
【提醒】不确定数据存哪就问，不要默认用内存库演示

「重启服务后再查一次」是最关键的一句：内存库和临时文件重启就清空，这一查立刻露馅。

它说「做好了」，你怎么自己验

这是本站的重头戏。AI 最会的不是写代码，是说「已完成」。这一条，它通常最多做到「运行时」这层：真的跑起来了，能在本机看到结果。

要亲眼看到这些，才算数

让 AI 启动项目，你在页面上注册一个新账号，然后让它执行查询，把这张表里你的记录原样列出来：id、你填的字段、时间都对得上。
关掉页面（或重启服务）再打开，确认数据还在——存在数据库里，重启不丢。
问清「连的是哪个库」：本地 SQLite 就是一个文件路径；远程库是地址 + 库名。确认不是连到演示用的内存库。
让它执行一条查询并贴原始返回（不是转述），你能看到真实的行。
涉及改数据（删、更新）之前，要求它先贴出「这条操作会命中哪些行」，并先做备份。

它常这么糊弄你

「数据已保存」——但其实是存在浏览器本地存储里，换浏览器或清缓存就没了。要问清存在哪。
为了演示方便用了内存库，重启就清空，却不告诉你。验收时加一条「重启后再查」的要求。
直接在生产库上跑 DELETE / UPDATE，没有备份也没条件限制，还说「删错了也容易恢复」——数据库的删除没有 Ctrl+Z。
改表结构（加字段、改类型）前没备份，老数据的格式对不上，整张表读不出来。

数据库能验到「运行时」层：数据真的存进去、重启后还在、能查出来。但「数据不会丢」到「生产」层，还需要备份策略、迁移流程、监控告警——那不是一个测试能证明的。

考考你选一个你觉得对的

AI 说「注册功能做好了，数据已保存」。你怎么证明数据真的存在数据库里而不是别处？

想再深挖一点靠谱出处

SQLite 官网sqlite.org ↗

# 数据库 (Database)

> 按结构长期存放、可查可改可删的数据系统；网页是看板，数据库才是仓库。

**你可能会这么说**：网站背后真正存数据的地方：注册的账号、发的帖子都存在这里，不在网页文件里。

你看到的网页是货架上的陈列，数据库是后面的仓库。关掉页面、甚至删掉整个网页文件，仓库里的货还在——下次打开页面，又从仓库把货搬出来。所以「关掉页面数据会不会丢」的答案取决于数据存在哪：存数据库里就不丢；存在页面代码里（写死的假数据）或浏览器本地存储里，换台设备或清一下缓存就没了。 最常见的是关系型数据库（MySQL、PostgreSQL、SQLite）：数据存在「表」里，表像 Excel——列是字段（用户名、邮箱、注册时间），行是一条条记录（每个用户一行）。表之间还能用共同字段关联：订单表记着 user_id 指向用户表。另一种常见的是文档型（MongoDB），直接存 JSON 文档，结构更灵活。选哪种不是玄学：要关联查询、结构固定选关系型；结构多变、以文档为整体存取选文档型。SQLite 特殊在它就是一个文件，不用装服务器，适合练手和本地小项目。 跟 AI 协作要守规矩，因为数据库是「有状态」的：改错了，数据真就坏了，而且删掉或覆盖的数据很难恢复，除非之前有备份——回滚代码救不了被覆盖的数据。所以涉及数据库的改动守三条：动手前先备份（导出）；先在测试库或本地跑，别直接在生产库执行；改数据（删、更新）先看清会命中哪些行。AI 为了演示方便有时用「内存库」或临时文件，重启就清空——验收时必须问清数据存在哪。

**也叫**：数据库、数据存储、存数据的地方、DB

## 你可以这样告诉 AI

```text
【任务】把 [注册功能] 的数据真正存到数据库里
【范围】只做用户注册这一张表和相关写入逻辑；不做登录、不改已有页面
【目标】用户注册后，数据能写进 [数据库名] 的 users 表，重启服务后数据还在
【边界】不要用内存库、不要用临时文件代替数据库；不要在生产数据库上直接执行未备份的改表操作；不要把密钥、连接密码写进代码
【交付】
  1. 连接的是哪个数据库、哪个库名：本地文件库给文件路径，远程库给地址和库名
  2. 注册一个新账号后，执行一条查询，把这张表里这条记录的原样输出贴给我（id、各字段、时间）
  3. 重启服务后再查一次，证明数据还在
  4. 告诉我数据存在服务器哪个位置、有没有备份
【提醒】不确定数据存哪就问，不要默认用内存库演示
```

## 怎么验证他真的做到了

通常止于层级：**运行时** — 真的跑起来了，能在本机看到结果

- [ ] 让 AI 启动项目，你在页面上注册一个新账号，然后让它执行查询，把这张表里你的记录原样列出来：id、你填的字段、时间都对得上。
- [ ] 关掉页面（或重启服务）再打开，确认数据还在——存在数据库里，重启不丢。
- [ ] 问清「连的是哪个库」：本地 SQLite 就是一个文件路径；远程库是地址 + 库名。确认不是连到演示用的内存库。
- [ ] 让它执行一条查询并贴原始返回（不是转述），你能看到真实的行。
- [ ] 涉及改数据（删、更新）之前，要求它先贴出「这条操作会命中哪些行」，并先做备份。

常见糊弄：
- 「数据已保存」——但其实是存在浏览器本地存储里，换浏览器或清缓存就没了。要问清存在哪。
- 为了演示方便用了内存库，重启就清空，却不告诉你。验收时加一条「重启后再查」的要求。
- 直接在生产库上跑 DELETE / UPDATE，没有备份也没条件限制，还说「删错了也容易恢复」——数据库的删除没有 Ctrl+Z。
- 改表结构（加字段、改类型）前没备份，老数据的格式对不上，整张表读不出来。

来源：https://mickerbook.com/reference/t/database/