一、从"文档"到"应用"：浏览器身份的变化

回顾 4.2：HTML 只干一件事——给内容贴标签。浏览器把标签解析成一棵树，然后按这棵树画页面。

那个阶段的浏览器，本质是一个排版阅读器。它做的事情是"把文档显示出来"。

变化发生在两处：

二、浏览器是怎么变成"应用容器"的

一个 Web 应用跑起来，靠的是四样东西各就各位（前三样你在 4.2、4.3 都见过）：

除此之外，浏览器还向网页开放了一批能力——你可以把它们想成浏览器发给网页的一个工具柜：

• 存东西：localStorage、缓存（不用联网也能记住一些设置）
• 画东西：Canvas（在线画图、在线修图的底子）
• 拿设备信息：当前位置、摄像头、麦克风、通知（每一次都要你点同意）
• 和服务器持续通话：WebSocket（聊天、多人同时编辑文档靠它）

三、一个操作背后，谁在干活

这是本节最该看懂的一张分工图：同一件事，被拆到了两个地方做。

一条铁律，值得抄下来：

3.1 两种请求：整页重来 vs 只搬数据

这里的 JSON 顺便值得认识一下：它是给程序吃的格式，长得像一堆键值对：

{ "now": "16:48:03", "user": "bozai", "unread": 2 }

对照 4.2 讲 HTML 的那句话就很清楚：HTML 是给人看的，JSON 是给程序吃的。 只不过两者进浏览器时都走同一套 HTTP（收 4.5），也都靠 Content-Type 告诉浏览器该怎么处理（收 4.6）——这一处正好把 4.6 那个"后缀 → 类型 → 浏览器行为"的链条又走了一遍。

四、Web 应用凭什么赢过"装在本机的软件"

这张表里有一条推论特别值得记住：

五、代价也很实在：Web 应用的四笔账

好处说完了，另外半张脸也得看清：

1. 服务器说改就改，你没有选择权。装在本机的软件，你可以不升级；Web 应用是"一次改动、全员生效"——昨天的用法今天可能就变了，而且没有"回退到旧版"这个选项。
2. 数据存在别人那里。服务一关停，你的数据能不能拿回来，全看它有没有导出功能——所以"能不能导出"是一个服务值不值得用的硬指标。
3. 离线就废。现在有 PWA / Service Worker 这类技术补一部分（能离线、能装到桌面像本地软件），但本质仍是补丁：数据最终还是要和服务器对齐。
4. 它是很耗资源的一种"软件"。浏览器同时开几十个标签页，就是同时跑着几十个应用——每个都在吃内存和电。

六、站在网络这一侧看：Web 应用改了什么

这一点是本章最该带走的视角转换——Web 应用把网络的"流量形状"整个改掉了。

于是 4.1 那句话有了后半句：

一次打开网页从来不是一次请求——而在 Web 应用里，其中很大一部分请求根本不是你点的，是应用自己在后台发的（自动保存、消息轮询、状态同步、埋点统计）。

这也解释了 4.5 讲的无状态为什么在今天更重要：每次自动请求都要自己带上凭据（Cookie / Token，收 4.7），服务器那边不记得你是谁。

七、动手 Demo（Demo47）：亲手看见"页面没刷新，内容却变了"

思路：用一个文件做一个最小的 Web 应用——一个页面 + 一个数据接口。点按钮时，页面上的时间会变，但整页不会刷新。这一眼，就是"网页"和"应用"的分界线。

第 1 步 · 新建 app_demo.py

import http.server
import json
import datetime

PAGE = """<!DOCTYPE html>
<html lang="zh-CN">
<head>
  <meta charset="utf-8">
  <title>最小 Web 应用</title>
</head>
<body>
  <h1>这是一个 Web 应用</h1>
  <p>服务器时间：<span id="t">（还没取）</span></p>
  <p>你点了 <span id="n">0</span> 次</p>
  <button id="btn">刷新时间（不刷新页面）</button>

  <script>
    let n = 0;
    document.getElementById("btn").onclick = async () => {
      const resp = await fetch("/api/time");     // 只取数据，不要整页
      const data = await resp.json();
      document.getElementById("t").textContent = data.now;
      n = n + 1;
      document.getElementById("n").textContent = n;
    };
  </script>
</body>
</html>
"""


class Handler(http.server.BaseHTTPRequestHandler):
    def do_GET(self):
        if self.path == "/api/time":
            body = json.dumps(
                {"now": datetime.datetime.now().strftime("%H:%M:%S")},
                ensure_ascii=False).encode("utf-8")
            ctype = "application/json; charset=utf-8"
        else:
            body = PAGE.encode("utf-8")
            ctype = "text/html; charset=utf-8"

        self.send_response(200)
        self.send_header("Content-Type", ctype)
        self.send_header("Content-Length", str(len(body)))
        self.end_headers()
        self.wfile.write(body)

    def log_message(self, fmt, *args):
        print("[服务器] " + fmt % args)


http.server.HTTPServer(("127.0.0.1", 8000), Handler).serve_forever()

第 2 步 · 起起来

python app_demo.py

第 3 步 · 打开页面

浏览器访问 http://127.0.0.1:8000。

第 4 步 · F12 → 网络面板 → 把筛选器点成 Fetch/XHR

第 5 步 · 连点几次"刷新时间"（本节核心现场）

你会看到：

• 页面上的时间变了、次数在涨
• 但页面没有闪，地址没变，整页没有重新加载
• 网络面板里只多出一条请求：/api/time，返回的是一小段 JSON

对比一下就懂了：按一下 F5，网络面板里会多出一条 document 请求，而且页面整体重画一次。

"整页 document" 和 "一小段 fetch"，就是网页与 Web 应用的分界。

第 6 步 · 点开那条 /api/time，看它的响应

{"now": "16:48:03"}

对照一下：4.2 那个 HTML 是给人看的（有标签、有结构），这一段是给程序吃的（只有数据）。同一条 HTTP 通道，运的东西不一样。

第 7 步 · 断网再点一次

点击后页面没反应，控制台报错——Web 应用对网络的依赖，就在这里。你本地那个 HTML 文件明明还在，可它没有数据可用了。

第 8 步 · 看后端那一侧的日志

app_demo.py 的窗口里，每点一次就落一行——你点的是界面，真正记事的在服务器（收 1.7 门房日志的老套路）。

八、30 秒实验

1. 30 秒：F12 → 网络面板 → 筛选Fetch/XHR`` —— 打开一个你常用的网站（邮箱、在线文档），什么都不点光看，也会有几个请求自己在跑。
2. 30 秒：在同一个网站上做一次操作（收藏一条、改个设置）—— 数一数多出来的是 document 还是 fetch。这一眼就是"文档"和"应用"的分别。
3. 30 秒：右键 → 查看网页源代码，再对照 F12 元素面板 —— 两处内容不一样（收 4.2）：源码是"送来的那份"，元素面板是"应用跑过之后的样子"。

九、常见误区

1. "Web 应用就是把网页做得花哨一点。" —— 判据不是花不花哨，是它是给你读的还是给你用的、有没有跑在浏览器里的程序逻辑。
2. "页面不刷新，就跟本地软件一样了。" —— 它仍然住在沙箱里：不能随意读写硬盘、不能改系统设置、每一次要设备能力都得你点同意。
3. "Web 应用不用安装，所以什么都没存到我电脑上。" —— 缓存、localStorage、Cookie（收 4.7）都在你电脑上，只是你"没做安装这个动作"而已。
4. "浏览器里打开的都叫网页。" —— 浏览器里可能跑着应用，也可能是本地文件（file://，收 4.2），还可能是个 PDF 阅读器。浏览器是个平台，不只干一件事。
5. "Web 应用每次操作都要下载整个页面。" —— 主流做法是只取数据（JSON）；每次整页重来反而是老旧的做法。
6. "服务器改版了，我这边不受影响。" —— 一次改动全员生效正是它的特点，而且你没有"回退旧版"这个选项（本机软件可以做版本选择，Web 应用不行）。
7. "数据放云端比放本机更安全。" —— 安全性取决于服务方怎么管，跟"在云端"没有必然关系；而且你同时把数据主权交了出去。
8. "前端界面写"最多 3 次"，那就只能 3 次。" —— 前端说的一切都在你的掌控范围内、也都能被改。真正的规则必须在服务器上判（本节第三节那条铁律）。
9. "Web 应用性能天生就差，做不了正事。" —— 差的是"受沙箱与 JS 限制"，但差距在缩小（WebAssembly 等），很多正经工作已经够用。
10. "SaaS 和 Web 应用是两码事。" —— SaaS 最常见的样子就是一个 Web 应用：软件在别人服务器上跑（收 1.7/1.8），你用浏览器"租着用"。

十、动手自测

十一、下一步学什么

• ☑ 浏览Web网站时的准备工作（访问Web时使用的应用软件与协议） —— 本节换个角度把整章点了一遍名：访问一个网站要先就位"一个会用 HTTP 的客户端 ＋ 一套配好的协议"。浏览器其实是一堆客户端拼起来的（缓存、Cookie、DNS、TCP、TLS、HTTP、渲染各一个模块）；敲下回车后六步依次上岗，一次访问至少动五个层。最后落在一张"网页打不开该先查哪儿"的对照表上。

相关笔记

• 审核公司员工浏览的Web网站（代理服务器的用途） —— 上一节：Web 应用大多跑在 HTTPS 上，这正是代理审核只能看到域名那一层的原因
• 制作Web网页（HTML） —— HTML 是"文档"那一侧的基础；DOM 树正是脚本能改的那棵树
• 设计Web网页的外观（样式表） —— 界面这一层怎么来的；样式与结构分离才有"应用"规模的可维护性
• Web网站是如何构建的（Web网站） —— 一次打开网页的几十上百次请求：本节补上后半句，其中很多是应用在后台自己发的
• 请求Web网站的文件（HTTP） —— 应用每次自动请求都要自带凭据，因为 HTTP 是无状态的
• 传输Web网站的文件（HTTP响应） —— Content-Type 决定"给人看的 HTML"还是"给程序吃的 JSON"怎么处理
• 记录Web网站的文件（HTTPCookie） —— 应用的状态（登录、购物车）靠这张纸条串起来；账本在服务器
• Web网站的地址（URL） —— 应用也用同一套地址；接口就是那些返回 JSON 的 URL
• 是谁在负责收发数据（应用程序、P2P应用） —— "应用程序是网络的主角"，Web 应用是最熟悉的一个例子；它的"客户端"就是浏览器
• 使用服务器的哪个部分？云服务的分类（SaaS、PaaS、IaaS） —— SaaS 最常见的样子就是一个 Web 应用
• 运行和管理服务器（服务器、云服务、内部部署） —— 后端程序与数据库就住在这些服务器上
• 根据端口号分配数据到应用程序（端口号、已知端口号） —— 本地起一个后端，"门牌号"就是那个端口（Demo 里的 8000）
• 对应用程序的数据进行可靠传输（TCP） —— 应用层的这些来回，脚下仍然是 TCP 在保送达
• 用于构建网络的设备（网络设备） —— 应用层的能力，最终都落在这些设备与主机上跑