一个请求是怎么流动的

现在我们把它们串起来。我们来跟着用户点击 "保存资料"，走过你刚刚认识的每一个部件。这是全书最有用的一个心智模型；如果你只内化一张图，就让它是这张。

1. 用户 点击 "保存资料"
        │
        ▼
2. FRONTEND（HTML 表单，JavaScript 读取这些值）
        │   发出一个 HTTP 请求：  "POST /profile  { name: 'Ada' }"
        ▼
3. HOSTING 把请求路由到你正在运行的 BACKEND
        │
        ▼
4. BACKEND
     ├─ 这个用户登录了吗？            (没有 → 响应 401，停止)
     ├─ 数据有效吗？                  (无效 → 响应 400，停止)
     └─ 都没问题 → 保存到 DATABASE
        │
        ▼
5. DATABASE 写入这一行，向 BACKEND 确认回执
        │
        ▼
6. BACKEND 响应：  "200 OK  { saved: true }"
        │
        ▼
7. FRONTEND 收到响应，更新 DOM
        │   ("资料已保存 ✓") —— 用户看到了它
        ▼
   完成

把每一层做了什么走一遍：frontend 收集了输入并把它发出去；托管 把请求送到了正确的地方；backend 执行了规则（登录、校验）并做了决定；数据库 把它变成永久的；然后响应一路流回来，好让 frontend 能更新屏幕。每一个应用都是这个循环的各种变体，每秒钟跑成千上万次。

注意那些检查全都发生在 backend，从不发生在 frontend——这就是第一节里那条规则的实际运用：frontend 是给用户的，backend 是给真相的。当你知道每一步发生在哪里时，你就能精确地描述一个功能（"保存之前在 backend 上校验邮箱"），而不是含糊地说（"把表单弄好"）——而精确，就是整场游戏的全部。