关于内容管理系统 (CMS)

内容管理系统 (CMS) 是一种用于创建、管理和修改网站内容的软件。它允许非技术用户轻松地更新网站，而无需编写代码。本文将介绍 CMS 的概念、用途、选型和开发要点。

什么是 CMS？

CMS 是一种软件应用程序，它提供了一个用户友好的界面，用于管理网站的内容。CMS 通常包括以下功能：

内容创建和编辑：允许用户创建、编辑和格式化内容。
内容组织：允许用户组织内容，例如创建分类、标签和导航菜单。
用户管理：允许管理员管理用户帐户和权限。
模板和主题：允许用户自定义网站的外观和风格。
插件和扩展：允许用户添加额外的功能，例如 SEO 工具、社交媒体集成和电子商务功能。

CMS 的用途

CMS 广泛应用于各种网站，包括：

企业网站：用于展示公司信息、产品和服务。
博客：用于发布文章、新闻和观点。
电子商务网站：用于在线销售产品和服务。
社区网站：用于创建论坛、社交网络和在线社区。
文档网站：用于管理和发布文档、手册和技术规范。

CMS 分类

根据不同的架构和用途，CMS 可以分为以下几类：

传统 CMS：如 WordPress、Joomla 和 Drupal，提供完整的前后端解决方案，适用于构建传统的网站。
Git-based CMS：将内容存储在 Git 仓库中，通过提交和推送来更新内容，适用于静态网站和文档网站。Git-based CMS 可以被认为是 Headless CMS 的一种特殊形式，因为它们通常不提供内置的前端展示，而是通过静态站点生成器（如 Jekyll、Hugo、Astro）将内容转换为静态页面。例如：
- Decap CMS：开源的 Git-based CMS，与 Netlify 平台集成。
- TinaCMS：提供可视化编辑界面的 Git-based CMS。
- Front Matter CMS: 一款开源的，基于 Git 的 CMS，直接在 VS Code 内部提供内容管理功能。它允许你使用 Markdown 或 YAML 文件来管理内容，并提供实时预览和内容验证等功能。
API-based CMS (Headless CMS)：只提供 API 接口，不负责前端展示，适用于构建各种应用程序，如单页应用、移动应用和物联网设备。例如：
- Strapi：开源的 Node.js Headless CMS。
- Contentful：云端 Headless CMS，提供灵活的内容模型和 API。
- Sanity：结构化内容云平台，提供实时协作和 GraphQL API。

选择 CMS 时，需要根据项目的具体需求和技术栈来选择合适的类型。如果需要构建传统的网站，可以选择传统 CMS。如果需要构建静态网站或文档网站，可以选择 Git-based CMS。如果需要构建各种应用程序，可以选择 Headless CMS。

更多 CMS 选型:

Git-based CMS 对比 API-based CMS：审核和内容管理流程的区别

虽然 Git-based CMS 可以被认为是 Headless CMS 的一种特殊形式，但它们在内容审核和管理流程上与 API-based CMS 有显著区别：

Git-based CMS：

内容存储： 内容存储在 Git 仓库中，通常以 Markdown 或 YAML 等格式存储。
内容创建和编辑： 内容创建和编辑通常通过文本编辑器或可视化编辑器进行，然后提交到 Git 仓库。
审核流程： 审核流程通常基于 Git 的 Pull Request (PR) 机制。内容作者提交 PR，审核人员审查 PR 中的更改，并提供反馈。只有经过审核并批准的 PR 才能合并到主分支，从而发布内容。
版本控制： Git 提供强大的版本控制功能，可以轻松回滚到之前的版本。
适用场景： 适用于静态网站、文档网站、博客等，内容更新频率较低，需要严格的版本控制和审核流程。

API-based CMS

内容存储： 内容存储在 CMS 提供的数据库中，通常以结构化的方式存储。
内容创建和编辑： 内容创建和编辑通常通过 CMS 提供的可视化界面进行。
审核流程： 审核流程通常由 CMS 内置的工作流引擎管理。内容作者创建内容后，提交到审核队列，审核人员审查内容，并批准或拒绝发布。
版本控制： CMS 通常提供基本的版本控制功能，但不如 Git 强大。
适用场景： 适用于各种应用程序，如单页应用、移动应用、电子商务网站等，内容更新频率较高，需要灵活的内容模型和发布流程。

总结：

特性	Git-based CMS	API-based CMS
内容存储	Git 仓库 (Markdown, YAML 等)	CMS 数据库 (结构化数据)
内容创建编辑	文本编辑器/可视化编辑器 + Git 提交	CMS 可视化界面
审核流程	Git Pull Request (PR)	CMS 内置工作流引擎
版本控制	强大的 Git 版本控制	基本的版本控制
适用场景	静态网站, 文档网站, 博客 (低更新频率, 严格版本控制)	各种应用 (高更新频率, 灵活内容模型)

选择哪种类型的 CMS 取决于项目的具体需求。如果需要严格的版本控制和审核流程，并且内容更新频率较低，则 Git-based CMS 是一个不错的选择。如果需要灵活的内容模型和发布流程，并且内容更新频率较高，则 API-based CMS 是一个更好的选择。

不同 CMS 在内容预览方面的区别

内容预览是 CMS 的重要功能，允许内容创建者在发布前查看内容的最终呈现效果。不同类型的 CMS 在内容预览实现上存在较大差异：

API-based CMS 的预览

API-based CMS 通常提供实时预览功能，内容创建者可以在编辑界面直接看到内容的最终呈现效果。预览的实现方式通常是：

实时渲染：编辑时实时将内容渲染为最终呈现效果。
预览 API：提供专门的预览 API，前端应用可以通过这个 API 获取未发布的内容进行预览。
预览环境：提供专门的预览环境，可以查看尚未发布的内容在实际环境中的呈现效果。

Git-based CMS 的预览

Git-based CMS 在预览实现上有更多的变化，主要可分为两类：

1. 使用 Git 托管平台 API 的 CMS

如 Decap CMS，TinaCMS 等，通过 Git 托管平台（GitHub、GitLab 等）的 API 进行内容管理：

优点：
- 提供在线编辑界面，无需安装本地 Git 客户端。
- 可以实现更接近于传统 CMS 的用户体验。
- 通常提供预览功能，但预览效果可能与最终网站上的渲染效果有差异，特别是对于使用特定框架或自定义样式的网站。
缺点：
- 通常需要配置认证和授权，设置相对复杂。
- 预览功能可能无法完全模拟最终网站的样式、布局和交互效果，尤其是对于复杂的页面组件和自定义 Markdown 扩展。
预览实现：通常通过内置的 Markdown 渲染器提供基本预览，或者通过创建临时分支结合预览环境来提供更接近最终效果的预览。由于必须推送并构建来查看实际效果，不能做到实时预览实际效果.

2. 基于本地 Git 客户端的 CMS

如 Front Matter CMS，基于本地 Git 客户端和编辑器（如 VS Code）构建：

优点：
- 与开发工作流更为集成，开发者可以使用熟悉的工具和环境。
- 不依赖外部 API，可以离线工作。
- 完全访问 Git 的所有功能和本地文件系统。
缺点：
- 通常需要安装和配置本地环境，对非技术用户不友好。
- 预览功能可能需要额外设置，如本地开发服务器。
预览实现：通常依赖于本地开发服务器（如 Astro、Next.js、Hugo 等的开发服务器），需要手动启动或配置额外的预览工具。

现代可视化页面构建型 CMS

除了传统的表单式 CMS（主要管理结构化内容），近年来出现了一类新型 CMS，如 Builder.io、Plasmic、Webflow、Framer 等，它们将页面布局、样式和交互设计也纳入了内容管理的范畴。这些系统提供了可视化的拖放式界面，使非开发人员也能创建完整的网页。

这类 CMS 的优点

无代码/低代码解决方案：营销人员和内容创作者可以在不依赖开发团队的情况下创建和更新页面。
缩短上线时间：新页面、活动页和落地页可以快速构建并发布，无需走完整的开发周期。
组件复用：开发者可以创建自定义组件，供内容创建者在不同页面中复用。
A/B 测试支持：许多这类 CMS 内置了 A/B 测试功能，便于优化用户体验和转化率。
适应不同设备：提供响应式设计工具，确保页面在各种设备上正常显示。

这类 CMS 的缺点

页面性能隐患：自动生成的代码通常不如手写代码优化，可能影响页面加载速度和性能。
复杂交互的局限性：对于需要复杂自定义交互的页面，可视化编辑器可能力不从心。
学习曲线：虽然比编码简单，但这些工具仍有学习曲线，特别是对非技术用户。
扩展性挑战：当需求超出系统预设能力时，扩展可能变得困难。
平台依赖：业务逻辑和页面设计可能与特定工具绑定，增加迁移难度。
版本控制限制：与传统代码相比，可视化编辑器的版本控制和协作功能通常更有限。

对开发工作流程的影响

采用这类 CMS 对开发团队的工作流程有以下影响：

开发角色转变

前期投入增加：开发人员需要前期投入更多时间来设计和构建基础组件库和集成点。
从页面构建到组件构建：开发人员不再负责构建完整页面，而是专注于创建高质量、可复用的组件。
技术支持角色：部分开发时间会转向支持内容团队使用工具和解决集成问题。

工作流程变化

开发与内容平行工作：开发团队可以专注于核心功能开发，而内容团队同时处理页面设计和内容。
迭代周期缩短：页面修改可以更快实施，不需要经过完整的开发周期。
质量保证挑战：需要建立新的测试和审核流程，确保由非技术人员创建的页面符合品牌标准和技术要求。

团队协作新模式

需要更紧密的跨团队协作：开发、设计和营销团队需要更紧密地合作，确保组件满足各方需求。
明确的责任界限：需要清晰界定哪些页面元素可由内容团队修改，哪些需要开发团队干预。
文档和培训需求增加：需要投入更多资源确保非技术团队成员能有效使用工具。

对开发成本的具体影响

可视化页面构建型 CMS 对开发成本的影响是复杂且多层次的：

前期开发成本增加

组件系统构建：需要开发更加通用、可配置且健壮的组件库，这比开发特定用途的组件要复杂得多。
集成工作：将 CMS 与现有系统集成需要额外的开发工作，包括数据同步、身份验证和权限管理等。
定制与扩展：大多数可视化 CMS 需要定制开发以满足特定业务需求，这增加了额外的开发工作。

长期开发成本权衡

简单任务成本降低，复杂任务成本提高：对技术人员而言，使用传统方法（如直接编辑组件）更新页面内容并不复杂。实际上，可视化 CMS 是在提高组件开发这一复杂环节的成本，来降低页面内容更新这一相对简单环节的成本。
技术债务风险：长期来看，随着业务需求的变化，通过可视化编辑器创建的页面可能会积累技术债务，因为它们通常难以系统性地重构。
维护负担转移：虽然页面更新的开发工作减少了，但组件维护、系统升级和解决与 CMS 相关的技术问题的工作可能会增加。

成本转移与效益分析

工作性质转变而非简单转移：可视化CMS并非简单地将工作负担从开发团队转移到内容团队，而是同时改变了两个团队的工作性质。开发团队的工作从”构建具体页面”转变为”构建抽象组件系统和集成点”，通常意味着前期工作量增加且技术复杂度提高。内容团队则承担了更多的页面组装和设计决策责任。
双方工作量变化：
- 开发团队：短期工作量增加（构建组件系统、集成和培训），长期可能减少重复性页面构建工作，但增加组件维护和支持工作
- 内容团队：工作量增加且工作性质变化，从提供内容扩展到页面布局和设计决策
规模效应：只有当需要频繁创建大量类似页面时，前期的高投入才能获得足够的回报。对于小型或内容变化不频繁的网站，这种投资可能无法获得正向回报。
总体拥有成本（TCO）：除了开发成本外，还需考虑许可费用、培训成本、系统维护和可能的迁移成本。

适合场景的细化分析

适合采用的情况：

有专职内容团队且页面更新频率高（每周多次）
开发团队资源有限，无法及时响应所有内容请求
内容更新的业务紧急性高，无法等待开发周期
需要进行大量的 A/B 测试或内容实验

不适合采用的情况：

小型团队中开发人员已经负责内容更新
页面设计和交互高度定制化
页面数量有限且更新频率低
预算有限，无法承担额外的前期开发投入

在决定是否采用此类 CMS 时，组织需要进行全面的成本效益分析，考虑团队结构、业务需求、内容量级和长期维护因素，而不仅仅是看表面上的开发效率提升。

适用场景

这类 CMS 特别适合：

需要频繁更新的营销页面和活动页
内容丰富但功能相对简单的产品展示页
有大量相似结构的内容页面需要管理
内容团队规模大且需要较高自主权的组织

不太适合：

功能复杂的应用程序界面
高度定制的用户体验
对性能有极高要求的页面
需要复杂业务逻辑的交互

与传统 CMS 的集成

现代开发方案常常将这类可视化页面构建器与传统 CMS 结合使用：

使用传统 CMS 管理结构化内容和数据
使用页面构建器管理页面布局和展示
通过 API 或插件将两者连接，实现内容和展示的分离

这种混合方案结合了两种系统的优势，既保持了内容管理的结构化和灵活性，又提供了可视化页面构建的便利。

CMS 开发要点

开发 CMS 需要考虑以下要点：

内容模型：定义内容的结构和字段，例如文章的标题、正文、作者和发布日期。
用户界面：设计用户友好的界面，方便用户创建、编辑和管理内容。
数据库：选择合适的数据库来存储内容，例如 MySQL、PostgreSQL 或 MongoDB。
API：提供 API 接口，方便其他应用程序访问 CMS 的内容。
安全性：确保 CMS 的安全性，防止未经授权的访问和数据泄露。
性能：优化 CMS 的性能，确保网站加载速度快。
可扩展性：设计可扩展的 CMS，方便添加新的功能和模块。

总结

CMS 是一种强大的工具，可以简化网站内容的管理。选择合适的 CMS 并遵循开发要点，可以构建出高效、安全和易于使用的网站。

为什么这个网站的新闻用 Git 管理?

用 Git 不需要本地部署后台或者购买托管服务, 简单又省钱
利用 Git 强大的版本控制能力
静态预渲染 Markdown 文件为 HTML 可实现极佳的页面加载速度、更好的SEO表现以及简化的网站托管方式
新闻发布不像商品发布那样需要很强的时效性, 半分钟左右的部署时间是可以接收的

为什么这个网站的页面文本不使用 CMS?

页面中的文本不是单纯的文本：页面包含响应式布局断点、主题切换样式配置、内联SVG图标与动态图形等高度定制化内容，这些元素需通过代码实现精确控制。传统CMS将这些降级为简单文本，无法保留完整的视觉和交互体验。
开发流程优化：对前端工程师而言，直接在组件中修改内容可立即预览效果，避免了CMS-API-前端的繁琐数据流转过程，特别是处理复杂布局和动态交互时更为高效。
成本收益比考量：考虑到页面内容变动频率低，投入资源搭建 CMS 系统的回报率不高，这些资源可以用于开发更有价值的功能。
技术栈精简策略：避免引入CMS可减少系统复杂度、降低潜在故障点、消除API依赖延迟，同时简化开发与部署流程，符合现代前端工程的”尽量减少依赖”原则。