Sveltia CMS：接替 Decap CMS 的 Git 式无头 CMS，迁移前先看这几点

它要解决的是 Decap CMS 留下的烂摊子

它的核心机制是 Git 即后端。内容以 Markdown 或 JSON 文件形式存在仓库里，编辑保存时直接提交到 Git。Sveltia CMS 本身是一个单页应用，托管在 CDN 上，没有自己的数据库。这意味着内容变更可追溯、可回滚，天然适合静态站点生成器（SSG）如 Astro、Eleventy 或 Hugo。数据流很简单：编辑器在浏览器里修改内容，CMS 调用 Git 提供商的 API 创建提交，然后 SSG 重新构建站点。这种架构的好处是部署简单，坏处是实时协作和富媒体管理受限，后面会细说。

上手三步：配置、认证、写作

根据官方文档，启动 Sveltia CMS 的步骤很直接。第一步，在静态站点的 index.html 里引入 CMS 的脚本，类似 Decap 的用法。第二步，创建一个配置文件，通常是 config.yml，放在站点根目录或 public 文件夹。配置里声明内容类型、字段、媒体文件夹和 Git 后端信息。第三步，配置 Git 提供商的认证，比如 GitHub 的 OAuth App。官方文档提供了迁移指南，专门针对从 Netlify/Decap CMS 过来的用户，强调高兼容性。实际命令和配置键在 README 里没有列出，但文档页有完整示例。注意，它要求你有一个 Git 仓库，并且站点构建流程已经存在，这不是开箱即用的博客生成器，而是给已有静态站点加内容管理层的工具。

i18n 是真正的卖点，不是附加功能

大多数 Git 式 CMS 的多语言支持都是事后补丁，比如用多个文件或目录硬分。Sveltia CMS 把 i18n 做成了第一等公民，README 里反复强调这一点。官方 showcase 里专门有一个筛选条件，列出使用 i18n 的站点，说明这不是宣传口号，而是有实际案例支撑。具体机制在文档里有说明，但核心思路是：在配置里定义语言列表，然后每个内容条目可以有多语言版本，编辑器界面提供语言切换，避免复制文件。这对跨国企业站或知识库特别实用。相比之下，Decap CMS 的 i18n 支持粗糙，需要手动管理翻译文件。不过，i18n 的配置复杂度不低，新手可能会在字段级翻译和条目级翻译之间犯迷糊。

移动端支持：听起来美好，实际有边界

README 宣称有移动端支持，这是 Decap CMS 明显欠缺的。编辑者可以用手机或平板登录 CMS 界面，修改内容并提交。这对需要频繁更新博客或产品页的团队是刚需。但要注意，移动端支持不等于原生应用，它仍然是响应式网页。在手机上编辑长文章或管理媒体文件，屏幕空间有限，体验可能不如桌面。另外，Git 操作在弱网环境下可能失败，因为没有离线队列机制。所以，移动端适合做紧急修正或短内容更新，不适合作为主要编辑环境。这个限制在文档里没有明确警告，但基于单页应用的架构可以推断出来。

兼容性是有代价的：别指望插件生态

Sveltia CMS 强调与现有 Decap CMS 安装高兼容，这降低了迁移门槛，但也意味着它继承了某些旧架构的包袱。Decap CMS 的插件系统不成熟，很多扩展是通过自定义组件或脚本实现的。Sveltia CMS 作为重写版，未必支持所有自定义逻辑。README 提到解决了 320 个问题，但没提插件 API 是否完全对齐。如果你依赖第三方小部件或自定义预览组件，迁移时可能得重写。另外，它是一个单页应用，所有功能都打包在一起，体积会随着功能增加而膨胀，但官方说它是“small, maintenance-free”，说明他们认为体积控制得还行。实际上，你无法像插件化 CMS 那样按需加载功能。

维护与升级：活跃但依赖单一组织

仓库的 last push 是 2026 年 8 月 29 日，最近一周内发布了三个版本（v0.201.0 到 v0.201.2），说明开发很活跃。License 是 MIT，可以自由使用和修改，没有开源合规负担。但维护集中在 sveltia 组织下，社区贡献渠道有 GitHub Discussions 和 Discord，但核心路线图由官方主导。这意味着如果你需要某个功能，得等官方排期，不能像自托管 CMS 那样随意 fork 后自己改。升级成本方面，因为它是 CDN 托管的单页应用，通常只需要更新引用的脚本版本，比传统 CMS 升级数据库 schema 简单得多。但要注意，频繁发版意味着你需要关注 changelog，避免新版本引入破坏性变更。

替代方案：Decap CMS 与静态 CMS 的取舍

最直接的替代是继续用 Decap CMS，毕竟 Sveltia 是它的继任者，如果你不介意旧界面和缺乏 i18n，Decap 仍然可用。但 Decap 维护停滞，安全问题可能得不到及时修复。另一个方向是使用非 Git 式无头 CMS，比如 Strapi 或 Directus，它们提供数据库后端和 REST API，适合需要动态内容、用户权限或工作流的场景，但需要自己托管服务器，复杂度高得多。Sveltia CMS 的差异在于它坚持 Git 即内容源，牺牲了实时协作和复杂查询能力，换来了部署简单和版本控制。如果你的内容模型很简单，就是文章和页面，Sveltia 是合理的；如果需要关系型数据或多人实时编辑，就该选数据库型 CMS。

编辑结论

Sveltia CMS 适合那些已经在用 Netlify/Decap CMS、受困于其维护停滞和编辑器体验的团队，尤其是需要多语言内容或移动端编辑的站点。它不适合对 Git 工作流无感、或希望 CMS 自带后端数据库的团队。采用前，先确认现有 Decap CMS 配置中的自定义组件和插件是否被兼容，尤其是那些依赖 Decap 内部 API 的扩展。其次，验证你的 Git 托管平台（GitHub、GitLab 等）的认证方式是否被支持，因为 Sveltia CMS 的认证流程与 Decap 有差异。最后，检查官方文档中的迁移指南，逐项比对配置字段，避免在 i18n 结构或媒体文件路径上踩坑。Sveltia CMS 的定位是轻量、免维护的 CDN 单页应用，不是功能无限的平台，边界清楚，适合就上。

官方来源

1. Official documentation
2. Official README
3. Project repository
4. Release notes