网站文件

我翻开一个老站点的网站文件FTP目录，看到里面躺着几十个后缀为.html的网站文件文件，文件名从index.html到about.html，网站文件再到一个叫old_news.html的网站文件。这些文件不是网站文件网站的全部，但它们是网站文件网站的最初形态——在数据库和内容管理系统普及之前，网站就是网站文件一堆文件的集合，服务器只是网站文件忠实地把这些文件按路径吐给访问者。

这个结构简单得近乎粗暴。网站文件你上传一个文件，网站文件它就在那里；你删掉，网站文件它就消失。网站文件没有后台，网站文件没有缓存，网站文件没有动态生成。网站文件每个页面都是孤立的，改导航栏得手动改每个文件，漏改一个就出现一个过时链接。我见过一个个人站2003年改版时，把首页的版权年份更新了，但内页还留着2001年的字样，那个错误在归档里躺了十几年，像一枚琥珀。

这种“文件即页面”的模型在今天看来笨拙，但它有一个被低估的优点：可预测性。你不必担心数据库连接超时，不用考虑模板引擎的继承关系，甚至断网时用记事本打开本地副本就能编辑。有个朋友至今运营着他的吉他谱站，几十年如一日地用纯HTML维护，问他为什么不换WordPress，他说：“我改一个错字只需要三十秒，那些系统光登录就要一分钟。”

当然，大型网站早就抛弃了这种模式。你访问电商首页，看到的其实是程序实时拼装的结果——商品价格从库存表里调，用户昵称从会话里取，页面框架是模板，内容是数据流。这时候“网站文件”的概念退居幕后，变成一堆分散的模板片段、样式表和脚本。你打开浏览器的“查看源代码”，看到的是一堆混乱的标签和转义字符，很难再找到一篇完整的文章或一个完整的页面。

有趣的是，这种转向带来一个副作用：网站的“文件感”消失了。以前你记得某个页面叫contact.htm，现在你只知道URL是一串无意义的路径，背后是某个控制器的某个方法。内容被拆碎，塞进数据库的字段里，再由查询语句重新拼接。效率上去了，但那种“我拥有一个文件”的踏实感没了。

我看过一些老站长写的文章，他们对这种变迁的态度很矛盾。一方面承认动态系统让维护变得轻松，另一方面又怀念当年手工调整HTML时的掌控感。有个比喻很贴切：静态文件像实体照片，动态网站像手机相册里的云端图片——后者更方便，但前者拿在手里有分量。

现在做网站又有了新玩法。静态站点生成器把Markdown文件编译成HTML，既保留文件的可读性，又自动化了重复劳动。我认识一个开发者，他的博客就是这种结构，源文件躺在Git仓库里，每篇文章是一个.md文件，构建时生成整个站点。他说这让他“重新找回了写文件的感觉”，而且版本控制让每次修改都有迹可循。

说到底，网站文件没消失，只是换了形态。从纯HTML到模板碎片，再到Markdown源文件，文件始终是内容的容器。变的只是我们如何看待它——是最终产物，还是中间原料。我总觉得，那些能让人直接打开、阅读、修改的文件，比藏在数据库深处的记录多一分亲切。就像纸质书和电子书的区别，后者容量大，但前者能在页边写批注。

下次你部署网站时，不妨看一眼服务器上的文件列表。如果是静态文件，你会看到一个个完整的页面；如果是动态系统，你会看到一堆php或py文件。前者的结构一眼望穿，后者需要追踪逻辑。各有各的妙处，但那份“文件即内容”的直白，正在成为一种稀缺品。