2.2 从点击保存到刷新不丢，Web 请求怎样走完一圈

上一篇我们说，校园小工具只要涉及多人访问、长期保存和统一维护，就很适合做成 Web 项目。

但很多老师一听到 Web 项目，马上就会被几个词吓住：前端、后端、接口、数据库。

这些词看起来像一堵墙。

其实先不用把它们想得太深。我们只要抓住一个真实动作：老师在排座系统里点击“保存座位表”。

这个动作背后发生了什么？

页面不是自己把数据存住的

先想一个很常见的现象。

你在一个网页表单里输入内容，如果没有保存，刷新页面以后，刚才输入的东西可能就没了。

这说明页面本身并不可靠。

它更像一张正在填写的临时表格。你在上面写东西，当然能看见。但如果没有交给专门保存数据的地方，页面一刷新，临时状态就可能消失。

排座系统也是一样。

老师把学生拖到座位上，页面能显示，不等于系统已经真正记住了。要想下次打开还在，就必须把这份座位关系交给后端处理，再存进数据库。

这就是 Web 项目和普通静态页面的重要区别。

前店、后厂和档案室

可以先用一个学校里更容易理解的比喻。

前端像前台窗口。

老师看见的按钮、表格、座位格子、提示文字，都在这里。它负责让人看得懂、点得动、操作顺手。

后端像后面的办事人员。

它不一定被用户看见，但真正处理规则。比如同一个学生能不能占两个座位，同一台电脑能不能分给两个人，保存时数据格式对不对，这些都应该由后端认真检查。

数据库像档案室。

班级名单、学生信息、机房座位、座位表关系，都要长期放在这里。页面刷新以后还能恢复，靠的不是页面记性好，而是档案室里有记录。

这三个角色合在一起，才是一个能长期使用的校园 Web 项目。

一次保存请求怎么走

现在回到排座系统。

老师点击“保存座位表”时，可以把过程想成这样：

flowchart TD
  A[老师点击保存座位表] --> B[前端收集当前班级和座位数据]
  B --> C[前端向后端接口发起 HTTP 请求]
  C --> D[后端检查数据是否合法]
  D --> E[数据库保存座位表]
  E --> F[后端返回 JSON 结果]
  F --> G[前端显示保存成功]

这里先不用深究 HTTP 的完整协议细节。你只需要知道：

前端不是直接伸手去改数据库。

它通常是把请求交给后端。后端检查、处理、保存，再把结果返回给前端。

返回的数据常常会用 JSON 格式。JSON 可以先理解成一种很规整的文本数据，前端和后端都容易读懂。

比如后端可能返回：

{
  "success": true,
  "message": "座位表保存成功"
}

前端收到以后，就能在页面上显示“保存成功”。

先看一个数据流转演示

下面这个小演示不是完整排座系统，而是一个简化版的数据流模型。

你可以输入数字 1 或 2，然后点击“发起请求”，观察数据如何在前端、后端和数据库之间流转。

演示里用的是“输入用户 ID，查询用户信息”。

放到我们的排座系统里，可以把它换个说法：

• 输入 ID：相当于选择某个班级或某张座位表。
• 前端：相当于老师看到的座位安排页面。
• 后端：相当于负责检查规则和处理请求的地方。
• 数据库：相当于保存班级、学生、座位关系的档案室。
• 返回结果：相当于把保存状态或座位表数据返回给页面。

所以不要被演示里的名字限制住。重要的是看懂这条路：前端发请求，后端查或存，数据库给结果，前端再显示。

为什么刷新后还能回来

很多校园小工具最容易翻车的地方，就是“看起来能用，但刷新后没了”。

这通常说明数据只停在了页面里。

比如 AI 可能生成一个很好看的座位网格，学生姓名也能拖进去。可如果它只是把数据存在浏览器当前页面的变量里，刷新以后变量清空，座位表自然就没了。

真正可用的排座系统，至少要做到：

• 当前班级是谁，要保存。
• 每个学生安排在哪个座位，要保存。
• 每个座位对应哪台电脑，要保存。
• 下次选择同一个班级时，要从数据库读回来。

这就是为什么我们一直强调数据库。

数据库不是为了显得专业，而是为了让系统有记忆。

接口是前端和后端约定好的门

还有一个词值得提前认识：接口。

接口可以先理解成前端和后端约定好的门。

前端不能随便乱敲后端。它要按照约定，把请求送到某个地址，并带上后端能理解的数据。

比如保存座位表的接口，可以粗略理解成：

POST /api/seating/save

意思是：前端把座位表数据发给后端，请后端保存。

读取座位表的接口，可以粗略理解成：

GET /api/seating?classId=701

意思是：前端告诉后端，我要读取 701 这个班级的座位表。

这不是让你现在背接口写法。你只要先知道：Web 项目里，页面和后端之间要通过一扇扇约定好的门来交换数据。

今天先记住一条主线

这一篇不要求你掌握 HTTP 协议，也不要求你会写后端接口。

先记住一条主线就够了：

页面负责操作，后端负责处理，数据库负责记住。

以后你看到“保存”“查询”“刷新后恢复”“多人看到同一份数据”，就可以先想一想：这件事是不是已经经过了后端？是不是已经进了数据库？

如果答案是否定的，那它多半还只是一个看起来像系统的页面。

想继续查，可以认这些词

这一篇讲的是一次 Web 请求的数据接力。下面这些专业词不用一次背完，但以后遇到报错、看 AI 生成的技术方案时，会经常碰到。

本文里的说法	专业技术名词	可以按需了解什么
老师看到并操作的页面	前端 / Frontend	HTML、CSS、JavaScript、Vue
页面背后处理规则的部分	后端 / Backend	Node.js、Python、接口逻辑
前端和后端约好的门	接口 / API	接口地址、请求参数、返回数据
前端把数据发给后端	HTTP 请求 / HTTP Request	GET、POST、请求体、请求参数
后端把结果返回给前端	HTTP 响应 / HTTP Response	状态码、响应体、成功或失败提示
前后端都容易读的数据格式	JSON	键值对、数组、接口返回格式
系统长期保存数据的地方	数据库 / Database	表、字段、记录、查询
刷新后数据还在	持久化 / Persistence	数据为什么要写入数据库或文件

下一篇，我们继续往外走一步。

现在本机浏览器已经能和后端、数据库完成一次数据流转了。但同事的电脑怎么访问你的项目？为什么你这里能打开，隔壁办公室却打不开？这就要看懂校园内网里的门牌号。

封面