gcms 为什么选 Go 和 SQLite：单二进制、单文件与适用边界

内容站的真实需求很朴素：把内容存起来，渲染成 HTML，让读者和爬虫都能稳定读到。gcms 没有把这件事做重，而是用 Go + SQLite 把运行形态压到最简单。

一个二进制

Go 把整个应用编译成一个静态可执行文件，embed.FS 把模板与静态资源一并打进去。部署没有「装运行时、装依赖、配环境」——上传，运行，结束。交叉编译到任意平台也只是换个 GOOS。

一个文件

SQLite 没有独立进程，读数据也不用走网络往返。开启 WAL 后读不阻塞写、写不阻塞读，瓶颈只剩「同一时刻一个写者」——对读多写少的内容站，这几乎不构成限制。

一套低维护的取舍

这类站点放在小规格机器上通常就够用。只是单文件数据库不等于备份时拷一个文件就行：gcms 开着 WAL，最近提交的内容可能还留在 -wal 里没并回主库。在线备份用 VACUUM INTO 或 sqlite3 的 .backup 导出一份一致副本；不方便装 sqlite3 的，就先停服，再把 .db 和同目录下的 -wal、-shm（如果有）一起拷走。uploads 目录和启动配置也要跟着备份。回滚时先停服，把现有的 .db、-wal、-shm 一起挪开，再放回备份的文件，否则留下的旧 -wal 可能被套到备份上把库弄坏。在你真正撞上「需要多机共享数据」之前，这套简单就是最划算的架构。

什么时候需要更重的架构

如果你的内容编辑每天都有大量并发写入、需要复杂审批流、需要多机同时写同一份数据，传统数据库和更完整的协同系统会更合适。gcms 的判断是：多数内容站首先需要的是可部署、可备份、可长期维护，而不是一开始就把复杂度拉满。