好久不见，世界！ • KMnO4y

你好！欢迎来到我的新博客。不出意外的话，之前的大部分文章已经按计划迁移到了这里。

来历#

六年来，我的博客系统一直是基于 Wordpress，因为我看重其易学和便捷的特性——不需要 Git，不需要构建流程，开箱即用，编辑可以直接通过网页面板完成。但是，随着我技术能力的提升，我开始希望添加调整或添加一些排版元素，而在 Wordpress 中，即使正确地加载了自定义插件，调整或添加的过程也难以在一个统一的地方完成——总是要在各种文件（PHP、HTML、CSS）间来回进行修改。此外，Wordpress 还逐渐显现出这些弊端：

Markdown 支持很将就：我愈发欣赏 Markdown 等纯文本格式的便利性和统一性，而 Wordpress 就连提供完善的 Markdown 支持都比较困难，网页面板上的编辑体验也难以匹敌本地的代码编辑器；
中心媒体库：图片、视频等媒体存储在中心媒体库中，而非与文章放在一起，难以追踪媒体被哪篇文章引用。尽管有插件可以提供这一项功能，但在 Markdown 和传统格式文章共存时，事情就变得更加复杂。“内存泄漏”（不使用的媒体没有及时删除）和“野指针”（清理时误删了正在使用的媒体）事故时有发生；
交互式内容支持较差：随着我的前端开发能力提升，我更希望尝试打破单页、静态、图文的写作方式，添加流程化的、灵活的甚至交互式的阅读体验，但这些在 Wordpress 上更是难以优雅地实现；
设计风格混乱：插件并非仅仅提供程序功能，还会提供管理界面。这原本正是 Wordpress 的便捷性所在，但设计风格五花八门的插件往往将管理面板弄得混乱不堪；
加载缓慢：Wordpress 系统每次访问都要查询数据库生成页面，网页加载慢是难以避免的问题。由于用户登录、评论等机制深度耦合在页面生成过程中，静态缓存也只是治标不治本的手段；
依赖外部资源：各种主题、插件会不可控地引用各种良莠不齐外部资源，难以完全防止引用 googleapis 的情况（由于众所周知的原因这会导致页面加载迟迟不能完成），并且任何被引用的外部服务爆炸都会导致功能异常（Gravatar 镜像源和 Editor.md 前端资源，说你们呢）。网站无法在没有人工介入的情况下保证长期可靠。

正是这些弊端让我不是很愿意在博客上写文章。我确实写了一些东西（例如学习笔记和信息安全大赛题解），但都不在这个博客上，这里已经好久没有更新了。曾经因为“便捷”被我选中的 Wordpress，早已成了我的负担。

以往，我对每次写一点东西都要打开代码编辑器大干一通的静态博客非常不屑，但如今，我发现我的大部分写作工作事实上都是在个人电脑上完成，仅有极少勘误和简单的文章会在手机上写作。在搜集相关信息后，我知道了即使静态博客也可以通过自动构建和 CMS 的方式进行网页端编辑，这完全可以满足我的勘误和简单写作需求。再不济，还可以用 GitHub 网页端修改代码然后直接提交嘛。或许，是时候务实一些，搭建一个自动构建的静态博客了。

技术框架概览#

之前我的博客都是在自己控制的云服务器上搭建，因此无论在资源使用、功能还是数据管理权上，都有很大的灵活性和自主性，PHP 应用的开箱即用特性更是让我能随时在网站上添加一些奇思妙想。即使改用了静态博客，我仍然希望有这样的灵活性和自主性，因此更偏好在自己的云服务器上部署网站，而非使用一些便捷且免费的服务。总而言之，现在的博客技术框架包含这些部分：

代码托管：网站代码，包括所有文章内容，托管于 GitHub。
静态站点生成器：这个框架要适合写博客，加载速度要快，还要有较多的主题/模板可供选择，还要能够与 npm 以及各种前端交互式框架原生集成。所以首先排除 Jekyll、Hugo 等不方便集成交互元素的，再排除不适合写博客（主要用来写技术文档）或者第三方主题很少的 Docusaurus、VuePress 和 VitePress 这些，留下的 Astro ↗ 正是符合这些要求的最佳选择。
网站模板：我现在的审美已经看厌了大红大紫，所以想要一个无主题色（但可以有强调色）或者主题色很淡的模板。我也不喜欢在文章页面上放一堆与文章无关的侧边栏组件。Pure ↗ 是淡主题色风格，甚至每篇文章可以自己有主题色，并且侧边栏放的是文章目录，该有的功能也都有。完美！
静态站点构建与托管：静态站点构建环境的维护成本较高，因此我选择用 GitHub Actions 在每次主分支发生 push 时构建。免费用户每月有 2000 分钟的构建时长，不太能用完。构建完成后，由 GitHub Actions 将文件通过 rsync 传输至我的云服务器，之后由 Apache 服务端负责提供页面。
CMS (暂缓)：计划使用 Decap CMS ↗ 提供 Web 编辑界面。CMS 所做的更改最后仍会以提交的形式反映到 GitHub 仓库中。由于使用 GitHub 网页端就能满足基本勘误需求，暂不折腾。Decap CMS 是几乎纯前端的，只需要与一个运行在后端的通用 GitHub OAuth 服务集成就行。
评论收集系统：由于 Pure 模板提供 Waline 集成，直接使用 Waline ↗。本站的 Waline 实例也部署在自己的云服务器上，使用 MySQL 数据库。

之后可能（我是说可能）会专门写文章详细解释技术框架和迁移流程。

原博客迁移公告#

~~似曾相识？~~

随着 Web 技术的更新，本站使用的 Wordpress 框架的弊端日益凸显——容易故障、文章撰写低效、无法轻易克隆、难以添加交互元素、维护成本高是其中显而易见的几个。

经过仔细的考虑，我们决定将此博客迁移至静态博客系统，新的系统将取代当前的 Wordpress 博客，域名保持不变，当前博客系统将同时关停。

迁移的明细见下方。

附属应用#

当前 ak-ioi.com 下的所有附属应用已经全部迁移并重定向到 apps.ak-ioi.com。接下来的迁移中它们不会受到影响。

文章#

文章的迁移具体视以下情况而定：

❎ (暂缓) 部分较新的文章会重写，以提供更好的阅读体验和更新的信息。
现在已经将这些文章标记为“处于待复核状态”。
✅ 2018 年 6 月的文章将被丢弃（它们来自更早的博客系统且现在已经没有实际价值）。
✅ 网页工具类的文章将被删除，部分工具后续会以纯前端的形式重新实现并添加。
✅ 未在存档页中列出，但是公开的文章，将被原样迁移至新的博客系统并且改为完全公开状态，不再隐藏。
✅ 隐藏且密码保护的文章将被放入不公开的存档中，不进入新的博客系统。
如果你将来需要这些文章中的内容，建议先保存其快照。如果迁移后仍需要访问，请在 2025 年 6 月 27 日前用任意邮箱发信至 webmaster at ak-ioi.com，附上文章密码的明文或者 SHA-256 哈希值，我们将手动提供被存档文章的副本。
✅ 完全不公开但目前有协作编辑的文章将被放入不公开的存档中，不进入新的博客系统。
如果你目前是协作编辑者，请在 2025 年 6 月 27 日前使用协作账号的注册邮箱发信至 webmaster at ak-ioi.com，我们将手动提供被存档文章的副本或访问权。
✅ 完全不公开且无协作编辑的文章，以及草稿文章，将被丢弃。
✅ 除了上述文章之外，所有其他文章将原样迁移至新的博客系统。

所有被迁移至新系统的文章，其永久链接都会改变。原先的链接处将添加软重定向页面。

文章元数据#

所有原有的分类目录和标签索引页将不会保留。新的系统将重新设计文章分类和索引页面。

指向原来分类目录/标签索引页的永久链接将完全失效（404），不会有重定向页面。

账户与评论#

所有当前系统上的已注册用户将不会保留。如果你是已注册用户，且需要协助迁出数据，请在 2025 年 6 月 27 日前使用你的注册邮箱发信至 webmaster at ak-ioi.com，我们将手动处理。

所有评论都不会以评论的形式转移到新的博客。具体视以下情况处理：

✅ 留言板页面的评论将清空。
✅ 在迁移中被丢弃的文章，其评论一并丢弃。
✅ (没有需要补充的内容) 提供了有用信息的博客和回复将补充到正文内容中，信息贡献者将被提名（只提及评论时留下的昵称，因为邮箱是不应该公开的敏感个人信息）。
✅ 所有带有提问性质且未得到回答的评论，将在迁移前后的一段时间内统一通过评论时留下的邮箱私信答复，此后评论将被丢弃。
✅ 其余评论将被丢弃。

新的系统仍会有评论功能，且所有可评论的文章评论区仍会无限期开放。