博客大修记录 (2026)
博客部署 总结篇
[2026-01-06]
Overview
搞完大论文，终于得闲处理一下早想加速的网站。
简单介绍。源站部署在 Gitlab (历史原因)，之前为了加速，做了七牛云的 CDN，但效果不尽如人意。此次博客大修，移除了很多组件，然而总嫌加载慢。
分析了一下，发现思路错了，想在境内访问加速，要做的是「国内镜像站」，而非 CDN。理由如下。
- CDN 是用首次回源延迟去换后续边缘访问加速，然而我的小站本来就没什么访问量，对于用户的体验便是：经常触发回源！因此体感上反而更慢了。
- 基于 CDN 加速，有一条关键路径，即边端节点到源站的访问。对于国内节点，访问 Gitlab 天然就是慢的，这条路径是无法加速的。(Gitlab 是真的拉完了)
当前方案。如上图。
基于此，便得到新的思路，直接在国内部署镜像站。选型后决定使用 EdgeOne，这真是赛博菩萨了，直接提供全球 CDN。这下不用自己做 CDN，连 DNS 分流都省了。而且操作容易，支持 Github、Gitlab 等，直接关联仓库便可构建。域名绑定体验也不错，自动续签。实测访问速度爽歪歪。
其他方案
在了解 EdgeOne 之前，另考虑了一些方案，记录如下。
国内 Pages + DNS 分流
之前国内可以做 Gitee 等，现在是收紧了，不再提供 Pages。又了解到 Gitlab 在国内搞了 JihuLab，去看了一下，气笑了，部署完 Pages 只能 Private 访问。(这放 Github 还算高级功能呢。) 再然后便只能是各种小厂提供 Pages 了，便宜有余，稳定性可能差一些，做备用线路还差不多。
思路如上图所示。
提供 CDN 自然是好的，如果不提供就只能自己做了，比如笔者一直在用的七牛云，还需要自己弄证书自动续签。之前为了备案，主域名 miyamura.top 是托管在腾讯云的，这样为了国内外分流，可以把源站域名 blog.miyamura.top 委派给 CloudFlare，这样就有 CF 提供的海外 CDN 了。
p.s. 开梯子走的是哪边？答案是国内，因为默认只代理应用层流量。
Serverless + 分流
国内也有一些，比如腾讯云和阿里云，或者用 Vercel、CloudFlare 等。提供 CDN 自然是好的，不提供就仍然自己做 + 分流。
自购 VPS
大厂略贵，2C2G3M 现在每年 618 和双十二还能淘到 99 一台的，带宽用起来跟挤牙膏一样。否则就找些小厂，能给到几十 M，但笔者不太可能会用。笔者觉得 Pages 就放到静态部署服务上。
CDN 在自部署 VPS 的情况下应该不是刚需了，如果带宽可以接受的话。
国内 Pages + 全球 CDN
比如七牛云，你自己不分流的话就只能勾选全球加速，否则境外访问它也给你走境内节点。主要考虑性能 (能否打过境外 CDN) 和成本问题。
源站 + 手动 CDN
Gitlab 的缓存刷新 TTL 是 600，这意味着 10 分钟 CDN 就过期了，之前不懂事，配 CDN 时勾选了「和源站刷新频率一致」，导致几乎每次访问都减速。于是又回到了前面讨论的关键路径问题。
笔者想了半天，最后的思路是，真沦落到这种方案的话，就自己写个刷新逻辑扔在 CI 流水线或者弄成 Serverless 服务。具体地，
- CDN 配置成永久 (实际上最多可选一年左右)
- 每次推送新更改后触发流水线，通过 API 刷新缓存
- 刷新后预热首页 (index.html 或 miyamura.top)
这样至少能保证首页加载速度。同时，因为 CDN 不刷新，即使网站访问少，时间久了缓存还是会逐渐加热。此为下下策。
对象存储 + CDN
第一次听到这个路子时有点震惊，这什么邪修思路。不过细想之下，原理是类似的。
家里云 + 内网穿透
算了
总结
不知道 EdgeOne 在当前这个时代背景下能提供服务多久，敢搞这种内容网站部署服务，腾讯后台还是硬，至少目前还是令人满意的。最后，尽量避免 CDN 套 CDN。
Github vs. Gitlab
无心插柳，在 Github 部署了镜像站。本来是以为 EdgeOne 不支持关联 Gitlab，所以想先镜像到 Github 再关联 EdgeOne，如下所示。
结果 EdgeOne 已经支持了 Gitlab，于是直接关联过去，这个 Github 镜像就悬空了。想了想，也部署了 Pages。
重点来了！ 部署完发现访问速度没比 EdgeOne 慢多少，远超 Gitlab。不禁怀疑，这两年过得都是什么苦日子。早知道 Github Pages 这么快，笔者连 CDN 都不搞。
Gitlab，你悔改罢！
