这次索性推倒重来。结论先行：首页从 7.06 秒 → 1.1 秒，外部请求从 8 个 → 0 个，页面体积从 200 多 KB → 28 KB。下面是完整过程，包括踩的坑。

一、先体检，别急着换工具

动手前我做了一件最该做的事：量化。

用 curl 把首页所有资源逐个打了一遍，结果很刺眼：

也就是说，服务器那 1 到 2 秒是正常的，剩下的 5 秒全在等别人的 CDN。

根因不难理解：jsdelivr 早年在中国大陆有加速节点，后来撤了，现在国内访问要绕到境外；而我的 Cloudflare 边缘又恰好落在阿姆斯特丹，一次 TCP + TLS 握手就是 250 毫秒起步，8 个资源叠起来就是好几秒。

这里有个方法论：慢的时候先分清是「我的问题」还是「别人的问题」。换主机、换框架是最容易想到的动作，但往往不是解法。

二、选型：三件事，不换的两件

生成器：不换

Hugo 已经是对的选择：单二进制、零运行时依赖、几百篇文章构建不到一秒、Cloudflare Pages 原生支持。换成 Astro 或 Hexo 只会增加构建复杂度，对这个博客没有任何收益。

主题：必须换

问题不在 Hugo，在主题。我抓了 11 个主流 Hugo 主题的 demo 站，只提取真实的资源请求（<script src>、<link rel=stylesheet>、<img src> 的域名），不猜、不凭印象：

PaperMod 是唯一同时满足「开箱零外链 + 持续维护 + 信息密度高」的。而且它有个隐藏优势：纯 CSS，不含任何 SCSS，所以不需要 Hugo extended 版本——在 CI 里少一个不确定因素。

它的字体直接用系统字体栈（-apple-system, "Microsoft YaHei"…），图标是内联 SVG，搜索用本地打包的 Fuse.js，全程不碰第三方域名。

部署：继续用 Cloudflare Pages，但换成「源码仓库」

原来的模式是：本地构建 → 把 public/ 推上 GitHub → Pages 直接发布产物。这叫产物仓库，问题是你没法在网页上改文章、也没法让 CI 帮你构建。

这次改成：仓库只存源码，Pages 直连私有仓库构建。

写作 → git push（私有仓库）
        ↓ Cloudflare Pages 自动构建（hugo --gc --minify，约 20 秒）
        ↓
   blog.xbta.cc（CF 边缘）

顺带说个容易被忽略的事实：Pages 的静态请求和带宽是无限免费的，只有 Pages Functions 才计入 Workers 配额。免费版的限制只有 500 次构建/月、2 万个文件、单文件 25 MB——对个人博客完全够用。

三、改造：不碰主题源码

我一上来给自己定了条硬规矩：themes/PaperMod/ 一个字节都不许改。

理由是可持续性。改主题源码的后果是：主题一升级就冲突，改了三处忘了一处，半年后自己都看不懂改了什么。正确姿势是把所有定制落在两个地方：

assets/css/extended/ 是 PaperMod 官方指定的定制入口，主题会主动加载它。这样以后升级主题，直接整个目录覆盖，零冲突。

具体定制按我自己的阅读习惯来：正文 760px、17px 字号、1.75 行高、浅色主题默认、列表不要卡片（一条细线分隔就够）、表格横向滚动不撑破版心。

四、图片：14 MB → 1.5 MB

36 张历史配图原来挂在 jsdelivr 的 GitHub 直链上，同样慢。这次全部迁到自己的 R2 图床：

• 格式：Pillow 转 WebP，质量 82，长边限制 1600px
• 结果：14 MB → 1.48 MB，省了 89%（单张典型值 225 KB → 28 KB）
• 缓存：对象上直接写 Cache-Control: public, max-age=31536000, immutable
• 访问：img.xbta.cc/blog/2020/xxx.webp

这里有个反直觉的发现：R2 的自定义域名不走 Cloudflare 的缓存层。我一开始给它配了一条「边缘缓存一年」的 Cache Rule，测出来 cf-cache-status 永远是 DYNAMIC，规则完全不生效。真正起作用的是对象自带的 Cache-Control——浏览器第二次访问直接命中本地缓存，零请求。

也就是说：R2 靠的是「浏览器缓存」而不是「边缘缓存」。知道这一点，就不用再浪费时间调规则了。

五、结果

现在整个首屏就是一个 HTML + 一个 CSS，加起来 28 KB，剩下的全是可缓存的图片。

六、踩过的四个坑

1. 图片下载的 403 不是限流，是 UA

批量迁移图片时，脚本一直返回 403。我先怀疑是代理限流，换了两轮实现才发现：python urllib 的默认 User-Agent 被源站拒了，加上浏览器 UA 立刻正常。

教训：批量跑之前先用一张图把链路打通（UA、长度校验、能不能被解析），别写完脚本再来试错。

2. 旧主题的短代码，新主题没有

文章里用了 LoveIt 的 {{< admonition >}} 提示块，换主题后构建直接失败：template for shortcode "admonition" not found。迁内容前应该先 grep 一遍所有短代码。

3. 改卡片样式漏了一个 border

PaperMod 的文章列表项默认是卡片（背景 + 圆角 + 边框 + 悬浮上移）。我去掉了背景和圆角，截图一看还是卡片——因为 border: 1px solid 还在。覆盖第三方样式必须对照它的源 CSS 逐条覆盖，只改显眼的那几个属性一定留尾巴。

4. 窄屏代码块溢出，首屏截图看不出来

手机宽度下代码块被右侧裁切，但首页截图完全正常——问题在页面下半部分。后来改成整页长截图 + 直接读 scrollWidth 和 clientWidth 才定位到。视觉验收不能只看首屏。

七、一点想法：天花板在哪

这套方案把「我能控制的部分」做到底了，但还有一段绕不过去：Cloudflare 免费版从中国大陆访问，TTFB 在 0.6–2 秒之间波动，因为边缘节点稳定落在我控制不了的地方（实测是阿姆斯特丹）。

这不是代码能优化掉的，是地理位置。想根治只有一条路：域名备案 + 境内 CDN，那是另一个成本和流程问题。

所以我的策略是承认它、然后绕过它：既然单次往返省不掉，那就让往返次数降到最少。1 个 HTML + 1 个 CSS，第一个字节到了页面就基本成型，剩下的图片慢慢来也不影响阅读。

体感上的「快」，很多时候不是 RTT 变小了，而是等待的东西变少了。

最后

这次重建真正的收获不是换了什么主题，而是那句最朴素的话：先量，再改。

如果不做那次体检，我大概会以为是自己服务器不行，去折腾主机配置、上什么加速服务——而那些全都解决不了问题，因为问题从头到尾都在别人的 CDN 上。

​ 彼岸图网 是一个很好的收集壁纸的网站，壁纸高清，我很喜欢，并且还赞助了会员。这次的爬取对象就是它了。

​ 这次的流程是先写爬虫脚本，然后放在VPS上爬取地址，最后用COLAB下载。

二、网站分析与确定爬取流程

1. 分析网页网址

   ​ 比如，我想爬取 风景 类的壁纸，先进入风景专区，然后点击一张图片的地址，发现此时的图片预览图是原图！！！那就可以确定爬取流程了。先以一张图为例。

   1.1 找到图片分类网址

   http://www.netbian.com/fengjing

   

   1.2 找到图片介绍地址和真实地址

   图片介绍地址：http://www.netbian.com/desk/23006.htm

   图片真实地址：http://img.netbian.com/file/2020/1108/1da1eab002604a8adcc33d8103b5758d.jpg

   

2. 确定爬取流程

   2.1 风景分类界面获取介绍图片代号

   2.2 图片介绍界面获取图片真实地址

三、写脚本

​ 以下为获取风景下图片链接的bash脚本，第一页的图片请单独处理。

#!/bin/bash
# 以下代码只处理第2-203页，第一页的图片请自行处理
# 定义种类kind为fengjing
kind=fengjing
# 定义页码page为2 3 .. 203
for page in $(seq 2 203)
do
	# 拼接种类页面链接kind_link
	kind_link="http://www.netbian.com/$kind/index_$page.htm"
	# 获取该页所有图片编号pic_num_list
	pic_num_list=$(wget -qO- $kind_link | grep -aoP "(?<=href=\"/desk/).*?(?=.htm)")
	# 定义图片编号pic_num
	for pic_num in $pic_num_list
	do
		# 拼接图片信息页面链接pic_info_link
        pic_info_link=http://www.netbian.com/desk/$pic_num.htm
        # 获取图片地址pic_link
        pic_link=$(wget -qO- $pic_info_link | grep -aoP -m 1 "http://img.netbian.com/file/20.*jpg(?=\" alt)")
        # 打印图片地址
        echo $pic_link
        # 保存图片地址到文件
        echo $pic_link >> ${kind}_down.txt
    done
done

注意

• grep -a可以查找二进制中的文字
• grep -m 1只保留第一次匹配
• 用wget -qO-而不用curl -s的原因是之后的grep -m 1查找到之后会堵塞通道造成错误

四、下载图片

​ 因为完全下载所需的空间需要几G之上，我的VPS不足以持，因此就用到了Google家的COLAB

1. 将爬取的下载链接上传到 谷歌网盘 的某个目录

2. 登录 COLAB 并新建笔记本，按照下图配置，然后依次运行即可

注意

COLAB 中 !开头表示运行SHELL命令

# 挂载谷歌硬盘
from google.colab import drive
drive.mount('/content/drive')
# 安装aria2
!sudo apt install uget aria2

# cd 到文件夹
!cd "/content/drive/Shared drives/1/fj"

!aria2c -i fengjing_down.txt

!zip fengjing.zip *

五、成品及反思

• 成品：彼岸桌面(http://netbian.com)_风景图片打包.zip

• 此次抓取中，有几点需要注意，

1. 下载网页源码之后可以找到文字，但用grep找不到，就是二进制文件的问题，加参数-a即可。
2. grep找到多个匹配，加参数-m 即可只保留第一个。
3. curl和grep连用有时会导致通道堵塞，使用wget -qO-全下载之后再grep即可。
4. COLAB中使用shell命令极大的增加了能力，并且可以挂载谷歌网盘，极大得方便文件的传输。

13015计算机系统原理-速记宝典.pdf 灵感来源于：rwkgygsing-box-yg.zip

总会有人，不同于其他人，聚在一起，分享美好的语句。

愿：所行化坦途，所求皆如愿。

2020年9月10日

本人利用空闲时间写一些自己遇到问题的解决教程和心得，欢迎大家关注！！！

最后我还是把网站建起来了

最后我还是用的这个喜欢的主题

最后我还是要写博客的

最后的我却渐行渐远