是的，我删掉了很多文章
主要是因为看起来过于……腻歪，就好像我为了建站而建站。虽然事实上我确实是通过这段时间的网站建设学到了很多东西，也可以说就是为了建站而建站吧。 另外就是觉得那些文章写得还是有点太水了，或者说过于稚嫩，不是很想继续展示在外面。就像是……黑历史一样。 倒是删掉的都是关于自建网站的内容，总感觉直接丢弃颇有浪费之意，于是便有了这篇文章以及这个标题。
关于域名
撰稿时，本站使用的域名已经是第二个了。 至于为什么弃用了原来的域名，只能说少不更事选了非常中二的而且现在的我相当不喜欢的一款，哎。 如果关注了本站很久的话应该知道有更换域名的事情，当时我设置了307 - Temporary Redirect来提示访客，现在已经停止重定向，原来的域名也已经在出售中。但是估计真的知道这件事而且不在我交际圈里的人并不存在。无论如何，我并不希望原先的域名出现在任何地方，或是被互联网记住。如果真的知道本站原来的域名，而又恰巧看到原来的域名在任何公开的位置出现，请按照关于中的邮箱地址联系我，十分感谢。如果是在非公开的位置记录下了本站原来的域名，还请进行更改。
关于渲染引擎：Hexo和Astro
心路
从一开始我使用的是Hexo这款“快速、简洁且高效的博客框架”，至于原因，是因为入门时看到了大量有关Hexo的入门教程，这也反映出Hexo社区大、文档完整，在博客框架界的口碑也相当不错。
期间一直使用的主题是Material。 因为从一开始其实是一个Android用户。大概是在在从Windows转移到macOS后，如何不那么别扭这篇文章发布前后买了台Mac，然后才慢慢进入了苹果生态。Android用户的话，就很喜欢Google的那套Material Design，而且这个主题当时就排在Hexo官网的主题页面很前面的位置。遇到这个主题也是一种缘分吧。
期间因为自己的折腾心就加了各种各样的魔改在主题里，可以去我的fork看一看：https://github.com/RiverKy/hexo-theme-material。
后来因为看久了有点审美疲劳，再加上Google自己都把Material Design从尖锐的矩形风格迭代成圆润的样式，再加上访问速度真的有点堪忧，再加上……忘了。就由于这些各种各样的原因，我一直盘算着换个主题。悄悄说：本来还打算一年一换的。后来发现自己好像还是有点太忙了，于是一直搁置着换主题的事情。
一直到2024年4月12日，想到每次Cloudflare Web Analytics给我发摘要邮件都会飙红的指标，我下定决心换一个主题。
本来打算用Sukka大佬的Suka，然后因为有点太简约又想去换个新的，兜兜转转，最后看到了Vivia。这个主题好啊，简约又符合当代各个科技厂商都倾向的圆润的大方向，结果一打开就是醒目的：
[!NOTE] This project is no longer actively maintained. If you are interested in this theme, it is recommended to use the new Astro version.
本项目已不再活跃维护，若对本主题感兴趣，建议使用新的 Astro 版本
于是我就自然而然地用了“新的 Astro 版本”。后来就是各种各样的迁移忙活了我两个周末，再后来就是你现在看到的这样啦。
为什么是Astro
对于我来说，Astro引擎加上Fuwari主题的好处还是相当明显的：
- 访问速度明显加快
暂时缓解审美疲劳- 又能学到新东西了
- Cloudflare Pages自带构建模版：以前用Hexo由于我技术力不够Cloudflare Pages老报错，非得回退到老版本的Pages构建环境才行
而其缺点也不少：
- 主题与引擎同构，欲更换主题比Hexo麻烦得多，此外主题的更新也成了问题
- 对于一些主题来说，可供自定义的选项貌似过少，例如像我使用的Fuwari，如果需要修改文章的路径将是一个大工程
- 使用很多插件都相当不方便，例如@astrojs/sitemap和@astrojs/rss。比起Hexo需要配置的地方多得多
- 项目文件夹过于复杂
- 社群小，教程少，文档不成熟
但麻烦是一时，流畅是长期问题。于是最后权衡之下我留在了Astro。
关于静态博客托管服务：GitHub Pages、Netlify、Vercel和Cloudflare Pages
心路
一开始还是因为大量教程选择了老牌的GitHub Pages。后来还是因为大量教程尝试了Netlify，试图搭建CMS并失败。后来又因为大量教程尝试了Vercel。最后是Cloudflare Pages最特别，给我发了推广邮件我就去试用了。
为什么是Cloudflare Pages
最后是因为我用它当权威DNS和CDN而一直用了下去。就是这么简单。颇有种「肥水不流外人田」的美。 其实真要说的话也完全有道理的，能省下很多Cloudflare的CDN回源的时间，从中间环节加快了访问速度。 而且他们碳中和啊。
各家服务的客观对比
以前对比优缺点，现在对比可用性，哈哈。针对的环境很明确的，不过多赘述。
GitHub Pages：
- 控制台（GitHub主站）连通性不佳
- 默认域名连通性不佳
- 自定义域名连通性正常，速度一般
Netlify：
- 控制台连通性不佳
- 默认域名连通性不佳
- 自定义域名连通性正常，速度一般
Vercel：
- 控制台连通性不佳
- 默认域名连通性不佳
- 自定义域名连通性正常，速度较慢
Cloudflare Pages：
- 控制台连通性正常
- 默认域名连通性正常，速度一般
- 自定义域名连通性正常，速度一般
下面是摘录的一些有关各平台主要功能限制的对比。但是我觉得大部分时候没有必要在意平台限制的，因为基本达不到。
我觉得没有必要的对比
GitHub Pages：
- 自定义域名：一个。
- 限制：
- （Git仓库）单个文件大于50MB将受到警告。
- （Git仓库）单个文件大于100MB无法上传。
- （Git仓库）项目总大小「强烈建议」少于5GB。
- 每小时可构建10次，每次不超过10min。
- 每月流量100GB。 详情可见：https://docs.github.com/en/pages/getting-started-with-github-pages/about-github-pages#guidelines-for-using-github-pages
Netlify：
- 自定义域名：多个。
- 限制： 对于每个账户：
- 同时只能构建一个站点。
- 每月流量100GB。
- 每月构建时间300分钟。 详情可见：https://www.netlify.com/pricing
Cloudflare Pages：
- 自定义域名：100个；
- 限制：
- 每月构可构建500次，每次不超过20min。
- 文件数量最多20,000个。
- 单个文件大小不得超过25MiB。 详情可见：https://developers.cloudflare.com/pages/platform/limits
Vercel：
- 自定义域名：50个。
- 限制：
- 每日可构建100次，但每小时不超过32次。每次不超过45min。每月总计不超过100h。
- 单个Git仓库支持连接3个Vercel项目。
- 每月带宽100次。 详情可见：https://vercel.com/docs/platform/limits
只能说希望大环境好一点。
写在最后
很感谢你能看完这篇文章，因为几乎没什么营养，就是一些无用的记录。虽然好像我的大多数文章都是这样。那么就先写到这里，期待接下来在Astro的驱动下我能有更好的写作体验，你能有更好的浏览体验。当然前提是我有心情和时间更新（）。
此致 顺颂时祺。