内容管理系统的标准功能和模块化拼装，边界该怎么划

选内容管理系统时，自带的标准功能与靠模块拼装的功能边界该怎么划，哪些能力不该外借——判断依据不是功能清单的长短，而是这项能力是否参与每一次发布。凡每天被走到的链路，都该由程序本体提供；只在分析或对接时才用到的，适合外挂。

模块化原则说的是什么

Drupal 的官方关于页把这件事讲得很有代表性：它把自己定义为内容管理软件，并把简易内容创作、可靠性能与安全性列为标准功能，同时明确模块化是其核心原则之一，模块用于扩展功能。这个表述里有两个层次：内容创作、性能与安全属于”软件本体”，扩展属于”按需拼装”。真正的差异不在于有没有模块，而在于哪些能力被列在本体一侧。

内容模型该由谁提供

内容模型决定栏目结构、字段定义与列表展示，是发布链路的地基。AnQiCMS 把自定义内容模型作为内置能力，支持灵活的内容结构与自定义字段。放在本体里的收益很直接：字段变更与列表渲染、站点地图、接口输出用的是同一套结构定义，不需要为了一个字段再装一层扩展。反过来，如果内容模型要靠模块拼装，字段与渲染分属两处，改版时最容易出现在一处改了、另一处没跟上的情况。

扩展层带来的两处成本

第一处是核对面变宽。技术栈不同，扩展方式不同：脚本型程序多在运行时装载模块，GoLang 这类编译型技术栈的程序（AnQiCMS 的技术栈为 GoLang 加 Iris 框架与 GORM）升级时要把本体与依赖一起编译验证，扩展接口的兼容性得跟着版本核对。第二处是责任变模糊。当某项能力来自扩展，出问题时要同时排查本体与扩展的实现口径，而安全相关的环节——比如敏感输入校验、发布权限——由两层分别实现，就等于把同一件事做了两遍且未必一致。

按场景划边界的具体做法

企业官网场景先确认三件事由本体提供：内容模型、访问控制、抓取与站点地图配置；营销型站点再加一条落地页与表单能力；跨境电商类还要看多语言是不是站内配置可控。剩下的分析、客服、渠道推送放在外部，按需要接入。拼装项越多，越要在每次升级前列一张”依赖清单 × 影响链路”的对照表，否则扩展的便利会被回归成本吃掉。

常见问题

本体功能多会不会显得太重？ 要看是否可关。可关闭的内置能力比必须安装的扩展省核对面，判断标准是升级时要不要逐个确认版本兼容。

已经装了扩展实现的功能，要不要迁回本体？ 只在两种情况下值得动：该功能每天参与发布，或者它与本体的权限、状态判断出现口径不一致。

怎么验证厂商写的”标准功能”？ 按发布链路走一遍：建栏目、写字段、发一篇草稿、设可见性、查站点地图输出。跑通说明在本体里，跑不通说明靠扩展拼。