HTML文件四种场景下的大小差异解析及测量内容咨询

嘿，这个问题挺细节的！我来给你逐个拆解下每个场景的大小差异原因，就拿你提到的页面举例：

• Ctrl+S保存为不含媒体的HTML文件（39kB）：
  说白了，浏览器用Ctrl+S保存的不是原始HTML源码，而是渲染后页面的“快照版”HTML。它会自动补全很多浏览器渲染时默认填充的标签（比如没闭合的<div>、缺失的<html>/<body>标签），还会把内联样式、脚本整理成更“规范”的格式，甚至可能附加一些浏览器自身的注释或格式信息。哪怕选了“不含媒体”，页面里的内嵌资源（比如内嵌CSS/JS）也会被包含进去，这些额外内容让文件比原始源码大了不少。

• Ctrl+U查看源码复制保存为TXT（17kB）：
  这里的源码是浏览器接收到原始HTML后解压并格式化后的版本。服务器发的原始HTML大概率是压缩过的，浏览器先解压，再为了方便阅读自动给代码加上换行、缩进（不然原始源码可能是一行到底的压缩格式）。复制保存成TXT时，这些额外的换行、空格，加上Windows系统下换行符从LF转换成CRLF（每个换行多1个字节），累积起来就比网络传输的原始压缩文件大很多。另外，保存TXT时的编码格式（比如带BOM的UTF-8）也可能额外增加几个字节。

• Chrome开发者工具网络面板的HTML文档大小（4.9kB）：
  开发者工具里显示的这个大小，是浏览器解压后的实际内容大小（也就是服务器发送的原始未压缩HTML的真实大小，可能因解压后的编码转换有微小字节差异）。你可以留意下网络面板的“Size”列，一般会分“Transferred”（传输时的压缩大小）和“Resource”（解压后的实际资源大小），这里的4.9kB就是后者——它是原始未压缩HTML的大小，比Ctrl+U的版本小，因为没加供阅读用的缩进和换行。

• Content-Length请求头（4.656kB）：
  这个是服务器在响应头里告诉浏览器的实际传输字节数，也就是经过Gzip/Brotli压缩后的文件大小。现在几乎所有服务器都会开启静态资源压缩，把原本十几kB的HTML压缩成几kB来提升传输速度。这个数值是最“纯粹”的——就是服务器发出去、网络上实际传输的字节数，没有任何额外格式或渲染补全内容，所以是最小的。

内容的提问来源于stack exchange，提问作者Evgeniy