# 插件系统定位讨论

> 日期: 2026-05-06 | 参与者: 产品负责人 + AI 协作
> 上下文: 夯实基础讨论中引申出的架构问题

## 背景

在讨论"冻结推迟模块"策略时，发现一个根本性问题：如果插件系统足够成熟，冻结功能 = 卸载插件，无需代码改动。当前 7 个模块需要通过菜单迁移和路由守卫来"冻结"，这本质上是架构不够灵活的症状。

## 战略方向

**通用基座 + 行业插件。** 一套底座代码维护，不同行业通过不同插件覆盖。医疗只是第一个行业，未来会有其他行业。

## 核心结论

**交付质量第一，插件化是理想状态。**

- 插件化是长期战略方向，但不是当前优先级
- 当插件开发能提供与原生同等的性能和体验时，才选择插件
- 当前阶段：用原生开发保证医疗功能的交付质量，同时积累"插件系统还缺什么"的实际数据

## 当初选择原生开发的原因及现状

| 原始限制 | 现在还是硬墙？ | 判断 |
|---------|--------------|------|
| JSONB 动态存储，不够强类型 | Generated Column 有类型约束，但 CHECK/FK/NOT NULL 仍缺失 | 半解决，医疗数据仍有风险 |
| 无自定义 API | 仍无，模板 API 覆盖不了趋势分析等 | ❌ 硬墙 |
| 无文件上传 | 仍无 | ❌ 硬墙 |
| 沙箱限制（加密、AI、外部调用） | 仍无 | ❌ 硬墙 |
| 实体上限 20 个 | 软限制，可调 | ✅ 已解决 |

**结论：医疗核心功能继续用原生开发是正确的选择。** 插件系统尚未准备好承载复杂医疗业务。

## 插件系统当前能力

11 个 Host API（全部实现）：CRUD + 事件 + 权限 + 多租户 + 配置 + 编号 + 日志

前端 7 种页面类型：crud, tree, tabs, graph, dashboard, kanban, detail

5 个已有插件：assessment, CRM, inventory, freelance, itops

## 插件系统 4 面硬墙及拆除评估

| 硬墙 | 工期 | 拆除方案 | 解锁能力 |
|------|------|---------|---------|
| 无自定义 API | 1-2 周 | `register-route` Host API，插件声明路由+handler，宿主注册到 Axum router | 趋势分析、报表、非 CRUD 端点 |
| 无文件上传 | 1 周 | `file-upload/download` Host API，宿主负责存储（本地/S3），返回文件 ID | 化验单、体检报告、头像 |
| 沙箱限制 | 2-3 周 | `encrypt-field` / `ai-analyze` / `http-request` 三个 Host API | 加密、AI 集成、外部系统对接 |
| 类型约束不足 | 1 周 | plugin.toml 增加 `required` / `constraints` / `ref_entity`，建表时生成 CHECK/NOT NULL/FK | 医疗级数据完整性 |

**合计：5-7 周**

### 各硬墙关键难点

- **自定义 API** — WASM 入参出参通过线性内存传递有开销；SSE 流式需宿主代理；路由冲突检测
- **文件上传** — 大文件需分块传输（WASM 线性内存有限）；文件与实体关联；权限控制
- **沙箱扩展** — `http-request` 需域名白名单防 SSRF；`ai-analyze` 需抽象多 provider；加密密钥插件不应接触 KEK
- **类型约束** — Generated Column 加 NOT NULL 后历史数据需补值；跨插件 FK 需特殊处理；约束变更迁移策略

## 投资时机

**当前决策：等医疗行业功能稳定后再投入。**

触发条件（满足任一即可启动）：
- 第二个行业确定要对接
- 医疗功能已稳定交付，团队有余力投入基础设施建设
- 特定能力（如文件上传）成为多个客户的共同痛点

## 行动路径

1. **现在** — 核心医疗功能继续原生开发，保证交付质量
2. **同时** — 在原生开发中记录"哪些需求插件系统无法满足"
3. **医疗功能稳定后** — 按触发条件评估是否启动硬墙拆除
4. **最终** — 插件能力足够时，新行业直接用插件开发，无需维护多套系统