为什么 gcms 能这么轻

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

一个二进制

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

一个文件

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

一套低维护的取舍

它能在一台很便宜的机器上稳稳服务一个中型站点。备份是复制一个文件，回滚是换回一个文件。在你真正撞上「需要多机共享数据」之前，这套简单就是最划算的架构。

什么时候需要更重的架构

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

复杂度被压到最低，而该有的能力，一个都不少。