Skip to content

简单谈谈我的建站历程

Published: at 11:15编辑

前情提要

除了几位从 2020 一直陪我到现在的小伙伴,其他人可能更多的是在 2023 前后才认识我的,为此我出一篇文章讲讲我的建站历史和现有的友情链接要求是怎么来的。

域名

我前后拥有了数十个二级域名,最早自己购买的域名是 liuzhen932.fun(注册于 2022-11-26),后来因为续不起费而切换到了现在的 liuzhen932.top。在此之前我通常使用 *.vercel.app 或者别的免费三级域名分发提供的三级域名

我遵循一个项目一个域名的原则,所以我拥有大量域名。这是不对的,要摒弃这种习惯,改成一个服务一个域名。

服务器

截止写稿,我目前拥有 21 台大大小小的服务器,其中部分为基于兴趣爱好搭建的,另一些可以算作是生产环境服务器。

因为我不会每天花费大量时间丢在博客互动上(这也大抵是我为什么回复很晚的原因),我觉得没必要给博客上服务器 —— 静态或无服务器部署就足够了,几经周折我最终将现在这个博客的访问交互放置在了 Cloudflare Pages 上。

我当然使用过 Vercel 和 Netlify 之类的 构建 -> 部署 服务。但我一直对这两家印象很差,其中一个原因是我的 Netlify 账户被无理由关闭了,另外的 Vercel 也在去年底给我发了一份天价账单(虽然最后投诉没收),之后的事情都知道了,我迁移到了 Cloudflare 或者自己的服务器上。

博客现在是一种伪动态的实现,通过客户端执行来假装页面是一个动态页面,一些博客有关的 API 我在去年年中使用 Golang 重构过(原来是 TypeScript),现在部署在一台海外 1000M 不限流机器上。

框架

我前后经历了这些框架的变动,具体的取舍我们一会再说:

这是用 PHP 搭建的轻量博客框架,我喜欢他的后台管理,不喜欢他的服务器需求(当时价格没有现在这么便宜),用过一段时间就换掉了。

毫无疑问 WP 是最受欢迎的博客框架,我很早之前使用过 WP Engine 提供的在线托管服务(当然最近他们和 WP 闹掰了),但是很明显一台低性能的机器被 itdog 测一下,CPU 会直接飞起来(有时 SSH 都连不进去),这影响了我对于这个博客框架的判断,我认为 WP 由于功能过于强大显得非常臃肿(还需要数据库,这不是很适合我一台机器多个站点的需求),不适合我。

如果你正在使用 WP 并希望提高加载速度,可以去看看 米露小窝,他的首屏优化做的很好。

我用过最早的主题,我使用过数十个主题(包括现在流行的),我也基于 butterfly 二开过主题,但是一个显而易见的问题就是那些时候我并没有那么多时间来折腾。

其次是一些性能考虑,Hexo 使用 NodeJS 编写,而 Hugo 使用 Go 编写,编译速度相比后者更胜一筹。NodeJS 通常使用 npm 来进行包管理,这也使得 node_modules 成为宇宙中最重的物体。

heaviest_objects_in_the_universe

同时我也不太喜欢 Hexo 的博文目录结构(当时可是一团糟,图片都不知道丢哪合适),现在看来换掉 Hexo 是一种合适的选择。

我看到一个 Hope 的博客主题很适合我,然后我去试了,之后调整各种配置文章就咕了

是的,VP 两个我都用过。对于 VitePress,我使用 Vue.js Blog 使用的主题修改而来,这对于很少的文章真的很简洁,但是对于数百篇文章,对不起,VitePress(至少在这个主题里)没有实现分页操作,这会让 DOM 变得超大影响加载和美观(甚至导致浏览器卡死)。

不知什么时候起,好多人都开始使用起了 Halo 这样一个框架(或者叫做系统),内存占用很大且很多主题和插件都需要付费,这对于我来说是不可接受的。不过有一说一用 Docker 部署和维护是很不错的产品定位。

请参考我这一篇文章来了解为什么我开始使用 Nextra

其实第二天我就换掉了 Nextra(笑)。Mx-space 是我写文章多的系统,前后有三十多篇,后来因为与开发者路线图想法不同奈何改不动而抛弃了这个系统。

旧站点截图

旧站点存档截图

我其实是推荐你使用的,后端占用不是很大,系统只需要 2G 内存即可轻轻松松跑起前后端,有能力你还可以给 @Innei 赞助。

请参考我这一篇文章来了解为什么我喜欢 Astro

主题

这里我只聊聊现在在用的 astro-paper 主题,这个主题给你的第一印象就是简洁,什么动效都没有,可以在 IE11 上完美浏览。

作者给出的 Lighthouse 满分,我测试了一下确实是这样:

满分

正如我之前提到的,我希望进一步优化博客系统的性能和用户体验,部署一套新的静态博客方案。最终的目标是找到一个既能保持高性能,又能满足我个性化需求的解决方案,然后一直用下去。

选择 Astro 的原因在上面提到了,无非就是它专门针对内容网站而设计的、我可以在一个页面里使用的框架(「Islands」)多和成熟的语法路由。Astro 越来越多的被各种文档站点采用,你可以前往 Starlight 了解一下

挂件

曾经我的站点也有很多 Live2D 或者樱花雨,但是我现在全部抛弃掉了,一个是感官确实不太好:我喜欢在文字上点击以确保我的注意力在鼠标那行文字上,如果你有点击特效我真的不习惯;另一个是个人观念的改变:我想要更为简洁的,更基础的互联方式,这也是为什么我的 IRC 在其他联系方式之上的原因(实际还是给我发邮件最好)。

注意:这是我的主观看法,这通常不会影响到友链的取舍。

洗涤恩

我的很多站长朋友都通过洗涤恩来加速服务访问速度以及隐藏源站,这里我推荐个人站长去看看 𝙌𝙞𝙪𝙙𝙪𝙣 𝘾𝘿𝙉,最早我为丘盾制作了一个简单的落地页用于收录引流(现在已经轮换为另一个模板了)。

𝙌𝙞𝙪𝙙𝙪𝙣 𝘾𝘿𝙉

这部分没什么好讲的吧?如果你想要实践向的优化教程请查看我的这篇文章

双栈访问

我是重度 IPv6 使用患者,这意味着我会假设你的站点有 IPv6 支持(直到我打不开)且我会优先使用 2a14:67c1:b066::/48 段内的某个 IPv6 访问(请检查 PTR 记录以确定是谁访问的)。如果您的站点支持 IPv6 访问,那么可以极大方便我对你的站点的访问。如果不支持也没关系,我会尝试回退到任意 HK 区域 IP 访问,国内站点则可能是湖北移动出口。

伪实时数据

目前我的所有站点均支持双栈访问。

统计

当一个人看到自己站点有很多访问的时候是很欣喜的,我也不例外。目前我是使用 Homelab 搭建的 Umami 统计系统,具体搭建方法看看就会了(通常限于我这种一天七八个个小时在终端前的人),不会可以参考一下 使用 Docker 搭建 Umami 这篇文章。

我目前运营一个半公益的 Umami 实例(代号 B),如果你有需求请联系我获得加入方式

总结

回首多年建站史,我逐渐从那个一无所知的小白成长为如今的新时代小白,从早期依赖免费三级域名到逐步建立独立域名体系,从试水多种博客框架到最终选择 Astro,这一路充满了技术探索与理念迭代。域名管理上,我摒弃了“一项目一域名”的冗余习惯,转而追求简洁高效;服务器部署方面,通过静态化与云服务优化,既降低了成本又保障了稳定性。在框架选择中,我经历了 WordPress 的臃肿、Hexo 的性能瓶颈、VuePress 的半途而废,最终因 Astro 的“内容优先”设计与轻量化特性而定下长期方案。

这一路的试错与调整,核心始终围绕“高效、简洁、可持续”展开。无论是框架迁移、架构重构,还是对交互细节的极致打磨,都旨在构建一个既能承载个人表达,又能为用户提供无负担体验的站点。未来或许仍会迭代,但此次总结的方案已接近我理想中的“长期主义”技术栈:以性能为基底,以需求为导向,持续精简冗余,专注内容本身

AQ 日常:👉 如果你对云服务器、CDN 等感兴趣或者单纯想在 QQ 上找我玩,欢迎加入南极洲日常群,交流极寒之地的所见所闻。

希望本文对你有所帮助,对本文有任何问题欢迎留言讨论!


上一篇
自建服务整理大合集
下一篇
域名:换域名吗?为什么不?

人机验证:请刷新页面以加载评论区