理解静态网站

这周我花了一些时间，把一个小项目重新用静态网站的方式做了一遍，此前它一直架在一个我从没真正搞懂的框架上。这个过程提醒了我，自己一直在承担多少本不必要的复杂度，只是平时没有意识到。

说得最直白一点，静态网站就是一堆文件：HTML、CSS，如果需要的话再加一点 JavaScript。没有服务器实时渲染页面，也没有数据库来决定给你看什么。服务器的工作被简化到最基本的一件事：有人请求，就把文件递出去。这种简单在你没意识到之前很容易被低估 —— 直到你花了一下午调试一个构建流程，才发现问题出在三层依赖之外的某个地方。

我具体做了什么

我把项目的内容搬成了纯 HTML 页面，共用一份样式表；写了一个小脚本，从文件夹里的内容自动生成索引和 RSS 订阅；然后把结果部署到一个普通的文件托管服务上。没有我看不懂的构建步骤，也没有需要持续跟进版本的框架。

代价是显而易见的：会失去一些便利。手写模板肯定比用组件系统慢。但我发现，放弃的那部分我大多并不怀念，而保留下来的东西 —— 秒开的页面，一个五年后不用维护也能正常工作的网站 —— 对于这么小的项目来说，是更划算的交易。

为什么这件事让我印象深刻

用尽可能少的活动部件去搭建东西，有一种特别的踏实感。我清楚地知道，当有人访问某个页面时到底发生了什么，因为文件和浏览器之间没有任何隐藏的环节。这种"看得透"，眼下对我来说，比几乎任何功能都更值得。

我不认为这是一个放之四海而皆准的答案 —— 很多网站确实需要数据库、实时内容或者用户账户。但对于像这个网站这样的个人档案来说，静态几乎是最理想的形态：耐用、运行成本低，也方便一年后我几乎忘光细节时还能看懂。

对于一个个人项目来说，最好的基础设施，往往就是你能完全装进脑子里的那一种。

随着这个站点内容变多，我大概还会继续写这方面的东西 —— 尤其是当笔记多到一个纯文件夹开始显得笨重的时候。目前来说，它运行得很好，也足够简单，让我信得过。