网站架构回顾与未来设想
2026-07-24 11:41:00 创建
2026-07-24 21:48:17 修改
从16号到今天，大约8天的时间，我把网站变得更好看了，也随之考虑稍深入的架构问题。写这样一篇文章，主要是想梳理一下到今天，我干了哪些事情，以及未来一段时间的设想，希望能把自己的思路变得更清晰。而当前这个页面，在新网站落成的那一刻，大概就废弃了。
对网站设计的简单回顾
样式设计
正如你看到的这个页面，之前的网站是很简陋的。从写完了反向传播的代码的那一天开始，我看着简陋的网站，便不再想学习强化学习了。这个原本的网站不仅外观简陋，而且在构建方面也毫无逻辑。所有文章都堆在一个文件夹下，文章命名全用日期，构建html页面是单个文章进行的，需要在写完一篇文章后手动运行构建脚本convert.ps1，一开始为了简洁、可控，用的方式都是最简陋的，每次运行起来还特别慢。创建日期靠Markdown里的front matter，修改日期竟然要靠构建脚本实时读取当前的系统时间，生成html页面之后还要手动在index.html里加入这篇文章的链接……实在是忍无可忍。因此，我萌生了把网站变得更好看，把架构变得更清晰，把构建过程变得更自动化，更方便，更统一的想法。
一切的开始，是学习如何做一个更好看的侧边栏。我跟着一个YouTube视频学做侧边栏。
我突然发现，看一个视频来学习，还真挺好的。比我自己问AI多少遍，或者上网上找多少文字教程，都有用。因为我在这个视频中看到了一个真实的开发者如何码字（快捷方式），以及一个更好的预览网页的方式（live-server），以及见到了开发中的真实场景（设计了多种语法以及真实的组合），看到了CSS是怎么写出来的，怎么和HTML中的class进行适配的。看到了我望文无法生义的语法，如果掌握了这些，我大概会对CSS更加了解。而这仅仅是一个视频的功效。
我大概明白为什么说YouTube是一个很好的（学习）平台了，因为你可以在这里看到各种事情。 或许我也要转变一下我的想法。我想要的是真实的表达。没有形式，纯文本固然精炼，但也容易让人感到枯燥。美本身就是我内在的表达之一，而视频可以以更丰富的形式表达，或许我以后可以考虑做视频了。
个人网站：留一个极简版，主要做更好看的网站，我现在觉得学CSS也没那么难了，几行js也很容易理解。接下来网站又可以完全回到我的掌控之中了。再度升起希望！
在做的过程中没有完全照着这个人的配色做，结果做出来很难看，然后又开始尝试复刻别人的侧边栏（“抄”别人的模板，虽然我最近一直以来都是反感模板的，但模板之所以成为模板，确实好看）。在做的过程中和AI交流了很多，也渐渐学到了一些CSS和html的知识，感觉做起来还是挺直观的。当时我就想，写CSS就像在画画一样，但完全不需要像画画一样担心手残，因为都是写代码，只要代码写好，做出来就是那样精确的。就这样，我终于把我的侧边栏做好了。
构建工具
做好侧边栏之后，开始思考网站的页面布局问题。我需要展示文章内部的目录，我有一个专栏，我还需要展示这个专栏的目录。侧边栏能不能行呢？总觉得着不下，即使加入右侧边栏。右侧边栏的作用是展示文章目录，但专栏目录就只能放在左侧的侧边栏下方，不是很好。所以从这时候开始，我就开始想办法把网页的布局改成顶部栏布局。这时参考了yang-xijie.github.io的收合顶部栏的想法，让AI帮忙写了一些这样的效果，结果虽然我没有显式指定，AI做出来的效果虽然用了不一样的收合方式，但也还挺好看。
在逐步完善顶部栏的过程中，我明显感觉到没有一个成体系的网站构建工具有多么复杂。想看看一种样式应用在整个网站中的效果，我还需要靠复制粘贴在各个栏目的index.html中来回修改内容、布局，但稍有不慎有的网页就漏改了一处东西。所以这时候，在一天晚上，我又让AI帮我写了一个最简单的小脚本，就是通过Node.js的fs，marked，来实现把一个特定的测试文件转化成html。这个流程很顺利就跑通了，这让我非常高兴，随后，在随后的一天内，我很快就在此基础上发展出了更多函数，用以实现更多的功能，整个网站的自动化构建（实际上是全量构建）到此也就初具形状了。而且相比原本的convert.ps1还要调用pandoc的powershell命令，Node脚本运行起来快多了。
网站架构
有了构建工具，修改网站起来就更加方便了。因为我只需要修改一处模板，构建出来的页面就都是一样的；而在运行本地服务器的时候，我只需要修改一处CSS，所有的页面就都会热更新。构建工具极大地提高了我设计、修改网站的效率，也因此，在把外观打磨到差不多的程度（具体来说是加入了自动构建的文章目录）后，我开始考虑网站的架构问题。
现在我在考虑更多的功能：
构建一个服务器，开发一个后台的编辑、上传、发布页面（当然也包括草稿箱功能）；然后前端就是当前这个静态网站。把这个功能做出来以后，我就有可能通过网页，在各个设备上撰写文章，甚至为手机开发专门适配的app。此外，我还希望加入隐私功能，也就是有些内容是涉及隐私的（比如学校的各种通知），不方便展示，但是放在个人网站上会更加有条理（比如我平时看到的各种文章，现在都是直接在微信或者telegram里转发给自己，现在有了个人网站可以更方便地、结构化地存储这些内容，这部分需与第一部分结合，即跨平台的上传功能）。这部分隐私内容只有我自己可以访问（目前只做到这个功能，未来或许还允许为其他用户添加权限，但那样的话就需要引入账密系统等等）。
之后的两天，我在AI的帮助下先是学习了cloudflare的functions，然后了解到workers；然后考虑到跨域请求的问题，把所有内容都搬到workers上，这样就不跨域了，也就不用管跨域请求了。
在确认这一点后，我开始了worker的实践。我直接把我前面开发网站的开发目录部署到了worker里，还测试了数据库的增删查改功能（AI写简单页面还真的很快）。随之而来的是一个不可忽视的问题：网络。由于cloudflare的workers默认子域名在中国大陆被DNS污染，无法直接访问。这对我的网站来说，显然是一个不便的因素，虽然未来可以通过自定义域名的问题来解决这个问题，但还是要买域名，不如直接就在现在想办法解决这个问题。
一开始因为公私分离的需求，AI推荐我把公开页面和管理页面分开为两个worker（这时仍然考虑公开页面上同时放置公开内容和隐私内容，隐私内容单独保护），然后管理页面通过Access来保护。但这时我考虑到上面提到的因素，觉得公开页面不能用worker，所以公开页面可以用Page+functions，而管理页面则用worker，不需要考虑别人访问的问题。
AI提醒了关键一点，说Access保护的是整个网页的内容，不能单独保护某个子目录，或者某些文件。因此我进而把公开页面和私有页面分离。公开页面使用Page+function，通过function读取数据库里的内容，在构建静态页面的时候只构建公开文章的页面，而从数据库读取数据并显示的时候只展示非隐私内容；而私有内容使用受cloudflare Access保护的worker，在构建静态页面时和展示数据库时不受限制，私有内容的worker还保留编辑文章和数据库的入口。这样就把公开内容和私有内容完全分开了。