ASP.NET Core CMS 架构建议：插件、主题与二次开发怎么落地
ASP.NET Core CMS 架构建议：插件、主题与二次开发怎么落地
如果目标是自研一套可二次开发、支持插件与主题的 ASP.NET Core CMS，首期最稳的方案不是追求“任意插件完全热插拔”，而是采用：
模块化单体 + 明确扩展契约 + 插件目录或 NuGet 包分发 + 受控重启加载。
热加载可以做，但不应该作为第一阶段的核心承诺。原因很简单：.NET 的 AssemblyLoadContext 能解决程序集隔离、依赖解析、并行版本和可卸载问题，但它不是安全沙箱。插件代码一旦进程内运行，就拥有宿主进程的能力。真正需要安全边界时，应使用进程、容器或操作系统级隔离。
一句话结论
首期建议做成：
- 模块化单体架构
- ALC 插件宿主
- 插件重启加载
- Razor Class Library 与文件系统主题并存
- EF Core 多
DbContext插件迁移 - 策略授权与资源授权
- NuGet 签名包分发
- 配套 SDK、模板和示例插件
二期再扩展受控热加载、多租户、更复杂的后台组件化。
为什么不建议首期追求完整热插拔
CMS 的插件系统看起来像“加载 DLL”这么简单，实际牵涉很多东西：
- 菜单注册
- 权限注册
- 路由注册
- 后台页面
- 数据库迁移
- 静态资源
- 定时任务
- 缓存清理
- 升级与卸载
ASP.NET Core 的 MVC 控制器发现更偏启动期。运行时可以通过 EndpointDataSource 或 Minimal API 管理端点，但“运行中动态增删复杂 MVC 页面”成本很高。
所以更稳的分层是：
| 能力 | 首期建议 | 后续增强 |
|---|---|---|
| 插件发现 | 扫描清单文件 | 插件市场 |
| 插件加载 | 重启加载 | 受控热加载 |
| API 扩展 | Minimal API / Endpoint Registry | 动态端点替换 |
| 后台页面 | 启动期注册 | 局部组件热更新 |
| 卸载 | 标记停用，必要时重启 | 可回收 ALC 验证 |
推荐的总体架构
这类 CMS 最适合做成模块化单体。宿主保持稳定，插件通过明确契约扩展能力。
推荐分层如下：
Cms.Host
启动入口、后台、静态资源、配置
Cms.Core
插件管理、主题管理、权限、路由、迁移、事件
Cms.Abstractions
插件契约、主题契约、菜单契约、权限契约
Modules
博客、媒体、搜索等内置模块
Themes
默认主题、企业主题、轻量主题
宿主只负责引导，真正的插件扫描、加载、菜单聚合、权限注册、主题解析、迁移执行，都交给 CMS 内核处理。
插件机制怎么设计
插件不要直接修改宿主内部状态，而是通过契约声明自己能做什么。
一个插件至少要包含：
- 插件编号
- 显示名称
- 插件版本
- 目标 CMS API 版本
- 入口程序集
- 入口类型
- 依赖插件
- 权限声明
- 是否签名
- 加载模式
示例清单：
{
"id": "Cms.Module.Blog",
"displayName": "博客模块",
"version": "1.2.0",
"targetCmsApiVersion": "[1.0.0,2.0.0)",
"entryAssembly": "Cms.Module.Blog.dll",
"entryType": "Cms.Module.Blog.BlogModule",
"dependencies": [
{ "id": "Cms.Module.Media", "version": "[1.0.0,2.0.0)" }
],
"permissions": ["blog.read", "blog.write", "blog.manage"],
"signed": true,
"reloadMode": "Restart"
}
插件加载流程建议固定为：
- 发现清单
- 校验版本、依赖和签名
- 加载程序集
- 注册服务、菜单、权限、路由和迁移
- 激活插件
- 停用、升级或卸载
这里最重要的是“先校验清单，再加载程序集”。不要一开始就把所有 DLL 反射进来。
主题系统怎么设计
主题系统建议用两种方式组合：
- 编译型主题：Razor Class Library
- 覆盖型主题：文件系统主题包
正式环境优先使用预编译主题，实施和二次开发阶段允许文件系统覆盖。这样既能保证性能，也能保留灵活性。
主题查找顺序建议固定：
- 当前站点覆盖视图
- 当前主题文件系统视图
- 当前主题 RCL 视图
- 默认主题
- 宿主共享视图
静态资源也要有明确前缀和回退规则，避免多个主题之间资源混乱。
不要把 Razor runtime compilation 当成生产环境主题热切换方案。生产环境更适合预编译主题、切换配置、清理缓存、刷新资源版本。
数据库迁移怎么处理
插件如果有自己的数据表，建议优先使用独立 DbContext 或独立迁移程序集。
这样做的好处是：
- 插件边界更清楚
- 升级更容易控制
- 卸载时更容易判断影响范围
- 多插件之间不容易互相污染
统一由 CMS 内核提供 MigrationRunner，在插件安装、升级和激活时执行迁移。
迁移策略建议“前滚优先，回滚保守”。上线后的内容系统经常包含真实数据转换，不要轻易承诺自动回滚所有变更。升级前备份数据库，失败时优先回退应用包和流量。
权限与安全怎么处理
权限建议分三层：
| 层级 | 用途 |
|---|---|
| 角色 | 后台常见权限集合 |
| 策略 | 插件注册的操作权限 |
| 资源授权 | 某篇文章、某个站点、某个租户的细粒度判断 |
插件可以声明权限，例如：
blog.read
blog.write
blog.manage
宿主通过动态策略提供器把这些权限接入 ASP.NET Core 授权体系。
安全上要特别注意：AssemblyLoadContext 不是安全边界。可信插件可以进程内加载，不可信插件必须进程外运行。生产环境插件建议强制签名，并维护可信作者或证书白名单。
运维与性能建议
CMS 后期常见瓶颈不是页面 HTML，而是：
- 插件扫描
- 插件加载
- 菜单聚合
- 权限解析
- 主题查找
- 数据库冷缓存
启动流程可以拆成两段：
- 必要阶段：读取清单、校验签名、建立扩展注册表、执行必要迁移
- 延迟阶段：预热模板、构建索引、恢复后台任务、刷新缓存
缓存层建议：
| 缓存层 | 适用内容 |
|---|---|
| 进程内缓存 | 菜单、权限元数据、主题描述 |
| 分布式缓存 | 多实例配置、投影数据 |
| 输出缓存 | 前台读多写少页面 |
日志和监控建议从第一阶段就接入结构化日志、健康检查和 OpenTelemetry，避免后期排障时没有入口。
八周落地节奏
| 周次 | 目标 | 交付物 |
|---|---|---|
| 第 1 周 | 宿主骨架 | 启动入口、配置、日志、数据库连接 |
| 第 2 周 | 插件加载 | 清单扫描、兼容检查、ALC 加载 |
| 第 3 周 | 扩展点 | 菜单、权限、事件、端点注册 |
| 第 4 周 | 主题系统 | 主题描述、视图覆盖、静态资源回退 |
| 第 5 周 | 数据迁移 | 插件迁移执行器、升级策略 |
| 第 6 周 | 安全闭环 | 动态权限、资源授权、签名校验 |
| 第 7 周 | 运维能力 | 缓存、健康检查、监控、CI/CD |
| 第 8 周 | 开发体验 | 模板、示例插件、示例主题、文档 |
最终建议
如果只保留一个工程决策，那就是：
先把 CMS 做成稳定的模块化单体，插件以重启加载为正式能力，主题以预编译与文件覆盖并存，权限和迁移从一开始就按插件化设计。
这样做不会限制未来扩展，反而能避免首期被热插拔、安全隔离和动态 MVC 发现这些高复杂度问题拖住。
