82 lines
4.3 KiB
Markdown
82 lines
4.3 KiB
Markdown
# 复杂度与价值评估
|
||
|
||
> 评估时间：Phase 0 实施完成后（2026-05-03）
|
||
> 评估范围：已实施的 Phase 0 + 远景 Phase 1~5
|
||
|
||
---
|
||
|
||
## 一、Phase 0 已投入的复杂度
|
||
|
||
### 1.1 新增代码量
|
||
|
||
| 文件 | 行数 | 职责 |
|
||
|------|------|------|
|
||
| `internal/plugin/plugin.go` | ~150 | 核心接口与类型定义 |
|
||
| `internal/plugin/adapter.go` | ~48 | CoreServices 适配器 |
|
||
| `internal/plugin/tab_registry.go` | ~98 | Tab 注册表（线程安全） |
|
||
| `internal/plugin/preview_registry.go` | ~80 | 预览注册表（线程安全） |
|
||
| `internal/plugin/manager.go` | ~196 | 插件管理器（生命周期） |
|
||
| `frontend/src/plugin/types.ts` | ~70 | TS 类型定义 |
|
||
| `frontend/src/plugin/registry.ts` | ~112 | 前端注册中心（Vue reactive） |
|
||
| `app.go` 改动 | ~40 | 集成 PluginManager + 2 个绑定方法 |
|
||
| **合计** | **~794** | |
|
||
|
||
### 1.2 架构复杂度增量
|
||
|
||
| 维度 | 具体表现 | 严重程度 | 已解决方式 |
|
||
|------|---------|----------|-----------|
|
||
| **Wails v3 方法泄露** | App struct 上所有导出方法自动暴露给前端 | 高 | adapter 模式隔离，CoreServices 独立实现（ADR-001） |
|
||
| **Vue 3 响应式陷阱** | `Map`/`Set` 在 `reactive()` 内不触发更新 | 中 | 使用 `Record<string, T>` 替代 Map（已踩坑记录） |
|
||
| **并发安全** | Manager 多处读写共享状态 | 中 | 全量 RWMutex 保护 + copy-then-iterate 模式 |
|
||
| **两阶段回滚** | Register 时 Tab 成功但 Preview 失败需清理 | 低 | `tabRegistered` 标志位 + `Unregister()` 回滚 |
|
||
| **前后端类型桥接** | Go struct → `map[string]interface{}` → TS | 低 | json.Marshal round-trip 统一处理 |
|
||
|
||
### 1.3 运行时开销
|
||
|
||
| 开销项 | 数值 | 说明 |
|
||
|--------|------|------|
|
||
| 启动时内存 | ~0（仅创建 Manager 和空 Registry） | Phase 0 不注册任何插件 |
|
||
| 锁竞争 | 无（Phase 0 无并发注册场景） | 为后续并发预留 |
|
||
| 方法调用链路 | App → pluginMgr → Registry | 多一层间接调用，可忽略 |
|
||
|
||
## 二、Phase 0 获得的价值
|
||
|
||
### 2.1 直接收益
|
||
|
||
| 收益点 | 说明 | 对应痛点 |
|
||
|--------|------|---------|
|
||
| **扩展骨架就绪** | 注册表、管理器、适配器全部可用 | app.go God Object |
|
||
| **新功能零侵入** | 未来新增预览格式 / Tab 页无需改 App.vue | 硬编码映射、v-if 链 |
|
||
| **懒启动支持** | Tab 插件按 `Start()` 按需激活 | 安装包膨胀、启动慢 |
|
||
| **优先级调度** | 预览处理器按 priority 排序匹配 | 无法控制预览顺序 |
|
||
| **内置/外置统一接口** | 同一套 Plugin 接口服务两类插件 | 两套逻辑 |
|
||
| **失败自动清理** | Register 部分失败时回滚已注册资源 | 残留脏状态 |
|
||
|
||
### 2.2 战略价值
|
||
|
||
| 价值维度 | 说明 |
|
||
|----------|------|
|
||
| **可演进性** | 从单体应用平滑过渡到平台型应用，每步可独立验证 |
|
||
| **文档资产** | 完整设计文档 + ADR + 接口定义 + 数据模型，新人可快速接手 |
|
||
| **技术债务清零** | 解决了 app.go 35+ 方法的 God Object 问题根源（不再往 App 加方法） |
|
||
| **市场基础** | Phase 0 的接口体系直接支撑 Phase 4~5 的外部插件和插件市场 |
|
||
|
||
## 三、远期复杂度预警（Phase 3~5）
|
||
|
||
| Phase | 主要复杂度来源 | 风险等级 | 缓解策略 |
|
||
|-------|---------------|----------|---------|
|
||
| **Phase 3** UI Slot 动态注入 | 9 个插槽的组件动态加载、生命周期协调、布局冲突 | 中 | 先做 2~3 个核心插槽验证，不全量铺开 |
|
||
| **Phase 4** 外部插件加载 | `.uplugin` 包解析、沙箱隔离、版本兼容、签名校验 | 高 | 参考 VS Code Extension Host 架构，独立进程运行 |
|
||
| **Phase 5** 插件市场 | 服务端 API、审核流程、支付、权限管理 | 极高 | 作为独立项目推进，不影响桌面端主迭代 |
|
||
|
||
## 四、总体评价
|
||
|
||
```
|
||
投入: ~800 行代码 + 6 个新文件 + 1 个文件改动
|
||
回报: 扩展能力从 0 → 完整骨架，后续每步增量开发
|
||
风险: Phase 0 本身风险已全部识别并解决
|
||
ROI: ★★★★☆ — 当前阶段性价比极高
|
||
```
|
||
|
||
**结论**：Phase 0 是一次高 ROI 的基础设施投资。真正的复杂度在 Phase 4（外部插件），但那是独立里程碑，可以单独做 go/no-go 决策。当前阶段建议继续推进 Phase 1（Draw.io 验证插件），用真实插件验证骨架的完整性。
|