df1d85bfde
- T40 UI 审计计划和结果文档（docs/qa/） - wiki 更新：miniprogram 设计系统合规审计记录 + index 关键数字更新 - 审计 V2 完整报告（docs/audits/v2/） - 讨论记录文档（docs/discussions/） - 设计规格和实施计划（docs/superpowers/） - 角色测试计划和结果（docs/qa/role-test-*） - Docker 生产部署配置
75 lines
3.8 KiB
Markdown
75 lines
3.8 KiB
Markdown
# 插件系统定位讨论
|
||
|
||
> 日期: 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. **最终** — 插件能力足够时，新行业直接用插件开发，无需维护多套系统
|