从输入网址到点击保存：一次请求怎样走完？

先修：第零章 · 核心学习无需安装

1.1 先把“看到了”和“保存了”分开

在笔记框里输入一句话，页面立刻出现新内容。你确实看到了它，但这句话在哪里？可能只在输入框里，也可能进入了浏览器本地存储，或者已送到某个服务。界面变化是观察，保存位置是需要证据支持的解释。

本章沿着一条消息往返，找出浏览器、应用和数据库各做了什么。你会现场观察公开课件的读取请求，再分析作者运行本机笔记服务时采集的写入记录。记录是一次已经发生的实验，不是你现在正在向云端提交数据。线上课件仍是静态页面，答案留在你的浏览器中。

1.2 现场观察：浏览器怎样取得课件

打开固定示例 线上课件首页。在该标签页打开浏览器的开发者工具，选择 Network／网络，保持记录开启，再刷新页面。筛选 Doc／文档，找到地址对应首页的一行。手机不便打开工具时，可以先完成下节的记录阅读，现场观察留到电脑上做。

1. 点开这一行，在 Headers／标头中找完整地址、Request Method 和 Status Code。
2. 确认方法为 GET，再在 Response／响应中找 HTML 正文。它是浏览器用来构成页面的文件。
3. 若看到缓存标记或 304，记录下来；可在工具打开时勾选 Disable cache／停用缓存，再刷新观察。拿不到页面时先检查联网和地址，不把环境失败当作概念错误。

这条路线是：浏览器请求页面 → 静态托管返回文件 → 浏览器解析并显示。200 表示这次请求成功处理；缓存也可能提供页面内容。它们都不能单独证明你的笔记被保存了，因为这次请求要的是课件文件。

1.3 地址找到对象，方法表达意图

把 https://system-design-course-8nv.pages.dev/ 分开看：https 指明通信方式，中间的域名定位站点，最后的 / 是请求路径。路径未必对应磁盘上的同名文件，也可能由应用处理。

请求还有方法、标头和可能存在的正文。方法 GET 表达读取资源；本章笔记接口用 POST 表达创建笔记，并在正文里携带 {"title":"第一条笔记"}。这叫 JSON：用字段名和取值描述数据。方法说明意图，应用代码决定如何处理，不能只靠名字推断内部实现。

1.4 完整往返：读列表，再创建一条笔记

现在换成课程提供的本机笔记服务。这里“服务端”是接收 HTTP 请求的程序，运行在你的电脑上；数据库也是本机 SQLite 文件。服务端不一定在云端，浏览器与它仍有明确的责任边界。

读取：浏览器 → GET /api/notes → 应用查询 SQLite
      浏览器 ← 200 与笔记列表 ← 应用返回查询结果

创建：浏览器 → POST /api/notes，正文包含 title
      应用校验 → 写入 SQLite 并提交 → 返回 201 与新笔记
      浏览器显示结果 → 再次 GET /api/notes 核查列表

读取让页面获得已有数据；创建才请求改变数据。本例约定：非空且不过长的标题通过校验，提交完成后返回 201。正文中的新笔记编号把这次响应与后来读取的对象连接起来。Network 只能直接给出请求和响应；“写入并提交”还要由已核查的实现与数据证据支持。

下面是作者真实运行服务后保存的记录。按顺序对照写入前、创建响应、写入后与重启后的数据。不要把记录里的日期、标题或结果当作当前网络状态；它说明这一次实验发生了什么，不保证任何未来请求都成功。

{
  "请求体": null,
  "响应": {
    "notes": []
  }
}

{
  "请求体": {
    "title": "第一条测试笔记"
  },
  "响应": {
    "note": {
      "id": 1,
      "title": "第一条测试笔记"
    },
    "storage": "sqlite"
  }
}

{
  "请求体": null,
  "响应": {
    "notes": [
      {
        "id": 1,
        "title": "第一条测试笔记"
      }
    ]
  }
}

{
  "请求体": {
    "title": ""
  },
  "响应": {
    "error": "标题需为 1–80 个字符的非空文本"
  }
}

{
  "请求体": null,
  "响应": {
    "notes": [
      {
        "id": 1,
        "title": "第一条测试笔记"
      }
    ]
  }
}

{
  "请求体": {
    "title": "测测测测测测测测测测测测测测测测测测测测测测测测测测测测测测测测测测测测测测测测测测测测测测测测测测测测测测测测测测测测测测测测测测测测测测测测测测测测测测测测测"
  },
  "响应": {
    "error": "标题需为 1–80 个字符的非空文本"
  }
}

{
  "请求体": null,
  "响应": {
    "notes": [
      {
        "id": 1,
        "title": "第一条测试笔记"
      }
    ]
  }
}

{
  "请求体": null,
  "响应": {
    "notes": [
      {
        "id": 1,
        "title": "第一条测试笔记"
      }
    ]
  }
}

1.5 错误提示只是起点，要查数据有没有改变

假设表单禁止空标题，点击保存时出现提示。若浏览器根本没发请求，这只证明表单拦住了输入。别的程序可以直接发送请求，所以应用收到数据后仍要校验。用户界面负责帮助输入，服务端负责守住自己承诺的数据规则。

查看记录中绕过表单的直接请求：发送空标题，再发送超过上限的标题。每次都要连接三份证据：请求确实发出，服务返回 422，前后数据库记录没有新增。实验区标明本例的长度上限。只看页面红字，甚至只看一个错误状态码，都少了数据核查。

还要区分另一类问题：甲、乙分别打开同一条旧笔记，各自修改后保存，这是两个不同编辑发生冲突；甲没收到回复而再次发送原操作，才是同一操作重试。当前演示只实现创建与读取，不实现编辑冲突处理。后续会分别讨论，不能以“加重试”回答所有保存问题。

1.6 换个场景：收藏夹真的收藏了吗？

你设计一个跨设备收藏夹。点击星号后它立刻变亮；新设备暂时看不到收藏。请写出至少两个可能解释，画出你期待的读写路线，并选择下一项核查证据。不要直接断言服务故障，也不要把按钮颜色当作数据库记录。

勾选只记录自评。若无法指出具体证据，回到对应小节补充答案，再带着这条读写路线进入需求设计。