实验 · 不占章号 / 配合第 2–3 章

午饭登记：看得见的软件

你每天都在用网页，但很少有机会看清“页面背后发生了什么”。 这个实验让你亲手填一次午饭登记，然后切换三种视角，看同一份数据在页面、接口和数据表里长什么样。

预计时间
10–15 分钟
前置
第 2 章 · 计算机与网络
关键词
页面、JSON、数据表、设备、登录、部署

做完这个实验，你能

  • 说出页面、接口 JSON、数据库表三者之间的关系；
  • 解释为什么换一台设备，记录就不见了；
  • 说清“部署”前后，网址和数据分别发生了什么变化。
先记住这一句

你在页面上看到的每一条记录，背后都有一份数据和一条请求。 这个实验把三者放在同一屏里，让你不用读代码也能看见它们。

这个实验在干什么

午饭登记是最小、最好懂的一个软件：同事填姓名和想吃的菜，组织者看列表。 它小到可以一个人做完，又完整到包含前端、接口、数据、登录和部署。

下面这个登记表真的能用：你可以添加、删除、切换设备、模拟登录和部署。 但它不联网，数据只存在你这台设备的浏览器里——这本身就是一个重要的知识点。

动手：登记一次

先填两个名字和菜名。提交后，切到“接口 JSON”和“数据表”看看同一份数据变成了什么。

http://localhost:8000/

模拟地址

当前设备

你的浏览器禁用了脚本，所以登记表是只读的。下面仍然可以看到三种视图的静态示例。

同事看到的页面

  • 小王 想吃 牛肉面 ·
  • 小李 想吃 番茄鸡蛋面 ·

接口返回的 JSON

{
  "source": "手机浏览器",
  "endpoint": "GET /api/lunch-orders?date=today",
  "orders": [
    { "id": "a1b2c3", "name": "小王", "dish": "牛肉面", "createdAt": "2026-10-19T04:01:00.000Z" },
    { "id": "d4e5f6", "name": "小李", "dish": "番茄鸡蛋面", "createdAt": "2026-10-19T04:03:00.000Z" }
  ]
}

数据库里的 lunch_orders 表

id name dish created_at
a1b2c3小王牛肉面12:01
d4e5f6小李番茄鸡蛋面12:03
试一遍：加一条记录 → 切到“接口 JSON” → 再切到“数据表”。 同一份数据，只是换了一种“说法”。
刚才发生了什么
  1. 还没有操作。

三种视图，其实是同一个东西

页面、JSON、数据表不是三个系统，而是同一份数据的三种呈现方式。可以把它想成一份菜单：

视图给谁看在软件里的位置你看到什么
页面 人 前端（浏览器里运行的界面） 姓名、菜名、删除按钮
接口 JSON 程序 后端提供的接口返回 一条请求对应的结构化数据
数据表 数据库 数据层（真正长期保存的地方） 一行一条记录，列是字段
停一下

为什么页面不能直接读数据库？如果每个同事的浏览器都能直连数据库，会发生什么？

实验一：换一台设备

  1. 用“手机”加一条记录。例如“小张 / 饺子”。记下列表里有几条。
  2. 切到“电脑”。列表变短或变空——因为你换了一套浏览器存储。
  3. 再切回“手机”。刚才那条又回来了。
  4. 点“清空数据”。两台设备都归零。
现实里对应什么

浏览器存储（localStorage）只属于当前这台设备、这个浏览器。 同事用他的手机打开你的页面，看到的是他自己的空列表，不是你的。

所以

只要数据还在浏览器里，它就不是共享的，也不可靠：换设备会丢，清缓存会丢，换浏览器也会丢。 要让所有人看到同一份数据，必须把它放到服务器上的数据库里。这就是第 3 章“数据层”要解决的问题。

实验二：要求登录

  1. 勾选“部署上线”，再勾选“要求登录”。
  2. 观察三种视图：登记表被禁用，JSON 变成 401，数据表显示“服务器拒绝返回数据”。
  3. 取消“要求登录”。数据恢复可读可写。

401 的意思是“我不知道你是谁”。服务器不是不给你数据，而是要求你先证明身份。 真实项目里，这一步会跳转到登录页；登录成功后，浏览器会带上一张“通行证”（通常叫 token 或 cookie）。

停一下

如果登录只发生在浏览器里，而数据还在浏览器里，换一台设备还能登录吗？为什么？

实验三：部署上线

  1. 先保持未部署，加一条记录。观察地址是 http://localhost:8000/。
  2. 勾选“部署上线”。地址变成 https://lunch.example.com/，数据源变成“服务器（共享）”。
  3. 勾选“要求登录”，加一条记录；再切到另一台设备，勾选登录。这条记录在两台设备上都能看到。
发生了三件事
  • 地址变了：从只有你能访问的 localhost，变成别人也能访问的域名。
  • 数据源变了：从“这台设备的浏览器”变成“服务器上的数据库”。
  • 多了 HTTPS：浏览器和服务器之间的内容被加密，别人截到也看不懂。
一个常见误会

“部署”不会自动把同事手机里的数据搬走。部署只是把程序放到一台一直开着的机器上； 数据要另外存进数据库，才会被所有人共享。

这不是真的服务器

这个页面没有联网，也没有真的数据库。它用浏览器存储模拟了“手机 / 电脑 / 服务器”三个位置， 所以你可以在一屏里看清状态变化。

真实项目里，这三件事分别由浏览器、后端程序和数据库完成。具体怎么选、怎么部署， 见第 3 章和 进阶：架构与选型。

三句话带走

  1. 页面、JSON、数据表是同一份数据的三种视图，分别给人、给程序、给数据库看。
  2. 浏览器存储只在这台设备上；要共享、要可靠，就得放到服务器的数据库里。
  3. 部署改变的是“程序和地址”，不自动搬数据；登录解决的是“服务器怎么知道你是谁”。

自测：三个问题

同事说“我打开你发的链接，里面是空的”，最可能是什么原因？

你发的是 localhost 地址，或者数据只存在你自己的浏览器里。 换设备、换浏览器都会看到另一份存储。

页面上的“删除”按钮，实际删的是哪一层的数据？

它先发一条 DELETE /api/lunch-orders/{id} 请求，由后端去数据库里删。 页面本身不直接碰数据库。

上线后为什么还要登录，而不是“有链接就能用”？

因为服务器要区分“谁在写、能写什么”。没有身份，任何人都能删别人的记录， 也无法追查是谁改的。

动手 10 分钟

把这个实验讲给一个完全不懂技术的朋友听，只用三个词：

  1. 页面（他看到的）
  2. 接口（页面和服务器之间的传话）
  3. 数据库（真正记住事情的地方）

如果他能复述“换设备为什么记录会没”，你就真的懂了。

如果你看到 X，大概率是 Y

  • 换设备后数据不见了 → 数据还在浏览器本地，没有进数据库。
  • 上线后页面能开，但功能全报错 → 后端的地址、环境变量或数据库连接没配好。
  • 登录后仍然 401 → 浏览器没有带上通行证，或者通行证过期了。

接下来读什么

想继续补地基：回 第 3 章《软件是怎么跑起来的》， 把五层结构和数据层看完。想直接选技术：去 进阶：架构与选型，从四套套餐里挑一套。