有一段时间，我特别喜欢给个人项目“上架构”。看到一个新技术，第一反应是“能不能用在我的站上”。那几年我的浏览器里存了大量架构图，服务器上却只有一个博客。
后来我慢慢放弃了这个习惯。下面这些方案，我都认真考虑过，有的还动手试过，最后大部分没有留下。写下来不是要证明它们不好，而是记录我判断“该不该用”的标准。
Kubernetes：为三个进程准备一个集群
我最想上的是 Kubernetes。理由听起来很充分：容器化、自动扩缩容、滚动发布、声明式配置。
真的算了一遍之后，问题很明显：我只有一台 2G 的机器，跑一个 Kubernetes 控制面就要吃掉大半内存；站点只有三个进程，扩缩容没有意义；滚动发布对一个月发布两次的博客来说，收益接近于零。
更重要的是，Kubernetes 出问题时，我需要理解网络插件、存储卷、调度器和一堆 YAML。这些东西的维护成本，远高于它带来的便利。
最后我用 systemd 加两个目录解决了发布问题：构建产物放在 releases 下，软链接切换，回滚就是换一个链接。二十行脚本，够用很多年。
Serverless：冷启动和调试的代价
有阵子我想把接口迁到 Serverless，按需付费、不用管服务器，听起来很适合小站。
试了一个原型之后，我放弃了。原因不是性能，而是调试体验：本地能跑，线上不一定；日志分散在各个平台；一次请求跨多个函数时，定位问题要来回跳。对一个月改一次接口的项目来说，这套心智负担不划算。
而且我的接口流量极低，Serverless 省下的钱，抵不上多出来的认知成本。
GraphQL：解决了一个我不存在的问题
GraphQL 很适合多端、多数据源、字段裁剪复杂的场景。我的站点只有一个前端，接口只有三四个，数据量很小。
引入 GraphQL 意味着要多维护 schema、resolver、鉴权和查询复杂度控制。它解决的“多次请求”问题，在我这里用两个 REST 接口就能覆盖。
我没有采用它。不是因为 GraphQL 不好，而是它要解决的问题，我还没有。
微前端：为一个人维护的前端拆边界
我一度想把博客和笔记站的前端拆成微前端，各自独立发布。听起来很整洁。
但我很快意识到：这两个站点的主题、组件和构建流程高度相似，拆开之后要维护两套依赖、两套版本和一套运行时集成。收益是“可以独立发布”，成本是“每次升级都要对齐”。
最后我选择让它们共用同一套 Hexo 主题文件，通过主题配置区分颜色和文案。简单，但有效。
自建评论与 Elasticsearch：两个吃维护的组件
评论系统我试过自建。要处理存储、反垃圾、邮件通知、审核和升级，任何一项出问题都要我自己修。后来换成了成熟的第三方服务，把维护责任交出去。
全文搜索我试过 Elasticsearch。为了几十篇文章，跑一个 JVM 服务，内存直接吃掉一大块。后来改成构建时生成静态索引，搜索在浏览器里完成，效果够用，成本几乎为零。
我保留了什么
放弃这些方案，不等于拒绝所有“先进”的东西。我保留了三样：
- 自动构建与部署：提交后自动构建、同步、切换，减少手工操作；
- 脚本化的基础设施：服务器初始化、备份、恢复都有脚本，换机器能重来；
- 加密的异地备份：用成熟工具，不自己造轮子。
这三样有一个共同点：它们降低的是“长期维护成本”，而不是“当下看起来很酷”。
我的判断标准
现在遇到一个新技术，我会问四个问题：
- 它解决的是我现在真实存在的问题，还是我担心以后可能存在的问题？
- 如果三个月不碰它，我还能不能看懂、修好？
- 它失败时，我能不能在半小时内定位到原因？
- 引入它之后，我多维护了几个东西？这些依赖会不会一起坏？
四个问题里只要有两个答不上来，我通常就不上了。
技术克制不是保守。它是一种资源分配：把有限的维护精力，放在真正影响可用性和内容产出的地方。对一个人维护的站点来说，最贵的不是服务器，是注意力。