New Site

从WordPress到Astro的技术演进

我的建站历程可以说是一部技术栈的变迁史。最早使用的是WordPress，当时觉得功能强大、插件丰富，但随着时间的推移，数据库维护和安全性问题让我开始寻找更轻量的方案。

于是转向了Typecho，这个轻量级的博客系统确实比WordPress简洁很多，但PHP环境的配置和更新还是让我觉得有些繁琐。后来接触到了静态站点生成器，开始尝试Hexo。

Hexo 基于Node.js，相比之前的动态博客系统确实轻量了不少。但当时我的笔记本还配备着机械硬盘，每次生成和调试都非常煎熬，即使线上CI生成速度并不慢，本地开发体验还是不够理想。

这时候我发现了Hugo，用Go语言编写的静态站点生成器。Hugo在本地可以快速编译，用起来很顺滑，解决了Hexo在机械硬盘上运行缓慢的问题。但Hugo的模板语言让我不太满意，没有编辑器的高亮与自动补全，也没有自动格式化代码的支持。由于后缀是HTML，每次格式化都会按照HTML的标准来，导致模板的各类函数被当成一般的字符串处理，代码的层级变得混乱。

经过对比，虽然Astro这类Node.js生态下的静态站点生成器在构建速度上比Go语言编写的Hugo稍慢，但开发体验和生态丰富度上的优势更加明显。牺牲一点构建速度换来更好的开发体验和丰富的生态，我觉得是值得的权衡。最终我选择了Astro，因为官方的文档写得很详细，对各类Worker平台的支持也很好。现在我的博客完全部署在CloudFlare Page上，既保持了静态站点的性能优势，又享受到了现代前端开发的便利性。

Astro的组件化优势

在这个项目中，Astro的组件化设计让我能够以模块化的方式构建网站。我创建了多个专门的组件，每个组件都有明确的责任范围，涵盖了导航、内容展示等核心功能。

通过组件化的方式，网站的各个功能模块都实现了独立管理。导航组件负责页面间的跳转和状态指示，内容展示组件优化了长文章的阅读体验，图片处理组件提供了友好的浏览交互。

这种组件化的架构让代码维护变得简单高效。每个组件都是独立的，修改一个不会影响其他部分。当需要调整某个功能时，我只需要专注于对应的组件，而不需要担心会破坏整个网站的结构。

相比于Hugo的模板系统，Astro的组件化让我能够以更现代、更可控的方式构建网站。虽然需要自己实现一些功能，但这种灵活性让我能够精确控制网站的每一个细节，打造出更符合个人需求的用户体验。

内容与存储

从七牛云切换到本地存储，是我在重构网站时做出的一个重要决定。现在的图片存储方案完全基于本地文件系统，通过 Astro 的静态资源处理机制来管理。

这种本地存储的方式有几个明显的优势。部署时图片会直接作为静态资源输出，不需要额外的 CDN 配置。所有资源都在同一个项目中，迁移和备份都变得非常简单。

在图片优化方面，我采用了 WebP 格式来平衡图片质量和加载速度。对于需要展示的图片，还实现了点击放大查看的灯箱功能，让图片浏览体验更加友好。

内容管理方面，我保持了 Markdown 的写作习惯，但通过 Astro 的内容集合功能进行了更好的组织。博客文章和日常记录分开管理，每篇文章都有独立的封面图片配置。这种结构化的内容管理方式，既保持了写作的自由度，又确保了网站的可维护性。

相比之前依赖七牛云的时代，现在的本地存储方案让我对内容有了更完整的控制权。虽然少了云端存储的便利性，但这种简单直接的方案反而更适合个人网站的需求。

总结

回顾整个建站历程，从最初的WordPress到现在的Astro，每一次技术栈的变迁都反映了开发体验和性能需求之间的权衡。

技术实现上，从动态博客到静态站点生成器的转变，让我更加注重开发效率和部署便利性。Astro的组件化设计虽然需要自己实现一些功能，但带来的灵活性和控制力是模板系统无法比拟的。

设计方面，极简的理念贯穿始终，黑白灰的配色方案和精心打磨的交互细节，都是为了营造一个专注内容的阅读环境。响应式设计确保了在不同设备和环境下的良好体验。

这个站点可能不会追求流量和功能复杂度，但它是我技术思考和实践的结晶。在这个信息过载的时代，能够拥有一个完全按照自己想法构建的数字空间，本身就是一种难得的自由。