# 前后端项目功能与开源组件可修改性分析报告

## 1. 分析范围与目标
- 前端项目：`F:/ips/node-test-mod`
- 后端项目：`F:/ips/java_test_back`
- 目标：
  1) 分析前后端主要功能定位与模块职责
  2) 重点分析前端关键页面涉及的核心组件是否开源、是否可修改

> 本次分析在 `glm47` 模型下完成。

---

## 2. 前端项目（node-test-mod）分析

### 2.1 技术栈与架构特征
- 框架：Vue 3 + Vue Router + Pinia
- UI：Element Plus
- 图编辑/流程建模：LogicFlow（含官方包与定制命名空间包）
- 构建：Vite（并保留 Vue CLI 启动脚本）
- 通信：Axios

项目路由显示目前核心入口页面为：
- `/` -> `plan-simulation-modeling/index.vue`

这说明该前端的主业务是“工艺/产线/计划仿真建模与生产控制配置”的单页主工作台。

### 2.2 页面功能拆解（核心页面）
根据目录结构，核心页面由以下子能力组成：

1. **Diagram 图形建模区**
   - 文件：`components/Diagram.vue` 与大量 `components/node/*`
   - 功能：节点、连线、箭头、图元、图标、路径图形的绘制与编排
   - 特征：包含大量自定义 Node/Edge，实现行业场景图元（仓储、工艺段、生产单元等）

2. **左侧建模工具/资源面板**
   - 文件：`left-sidebar-config/*`
   - 功能：不同建模域（如 PHMM / PRCM）的图元选择与配置入口

3. **顶部工具栏**
   - 文件：`top-sidebar-config/DiagramToolbar.vue`
   - 功能：缩放、回退、前进等画布操作，流程编辑辅助

4. **属性面板（设备/连接/工艺属性）**
   - 文件：`equ-attribute-config/*`
   - 功能：不同实体（设备、线段、仓库、关系链接等）属性编辑
   - 特征：按类型拆分细粒度组件，适合扩展复杂业务属性

5. **生产控制配置（多维控制）**
   - 文件：`production-control/*`
   - 功能：区域、线、段、单元、组合仓等控制策略配置

6. **TOB 生产相关页面**
   - 文件：`tob-production/*`
   - 功能：切批、仓储生产、单元生产等业务规则配置

7. **API 分层清晰**
   - 文件：`src/api/*`
   - 分类：生产控制、工艺路线、TOB 生产、仿真包配置等

### 2.3 前端项目总体判断
这是一个“行业仿真建模 + 生产控制配置”的复杂业务前端，强图形编辑能力 + 强配置能力并存，属于中大型业务平台前端。

---

## 3. 后端项目（java_test_back）分析

### 3.1 架构与技术栈
- 多模块 Maven 聚合工程（`packaging=pom`）
- Java 8 + Spring Boot 2.3.12 + Spring Cloud Hoxton + Spring Cloud Alibaba
- 数据与中间件：MySQL、Redis、MyBatis-Plus、Druid
- 安全与接口：Spring Security、JWT、Swagger

### 3.2 模块职责（按命名与控制器分布）
- `business-common`：权限、字典、日志、监控、在线会话等通用能力
- `business-core`：仿真主流程、仿真项目、任务、统计、结果分析、记录
- `business-support`：基础主数据、工艺定义、日历、BOM、PHMM/PRCM 等业务支撑
- `business-mansch`：排产/调度（FIFO/FEFO 等版本）
- 其他：`application/config-*` 负责启动与配置

### 3.3 控制器规模（粗粒度）
- `business-common`: 8
- `business-core`: 15
- `business-support`: 42
- `business-mansch`: 2

说明后端侧重点是“业务支撑与配置域（support）+ 仿真核心域（core）”。

### 3.4 后端总体判断
后端是典型“仿真业务平台”的分层多模块实现：
- 通用安全与治理能力完善
- 业务实体与工艺模型 API 丰富
- 可支撑前端图形建模页面的复杂配置与数据回写

---

## 4. 前端关键组件开源与可修改性分析（重点）

### 4.1 关键组件与许可证结论

1. **vue**
- 许可证：MIT
- 是否开源：是
- 可否修改：可以（可 fork/patch；注意保留许可证声明）

2. **element-plus**
- 许可证：MIT
- 是否开源：是
- 可否修改：可以（常见方式：主题变量定制、二次封装、必要时 fork）

3. **vue-router / pinia / axios / sortablejs / preact**
- 许可证：MIT
- 是否开源：是
- 可否修改：可以（通常建议“封装优先、fork 兜底”）

4. **@logicflow/core / @logicflow/extension**
- 许可证：Apache-2.0
- 是否开源：是
- 可否修改：可以（允许商用与修改，需遵守 Apache-2.0 的 NOTICE/License 要求）

5. **@helinda-test-logicflow/core / extension**
- registry 元信息显示：Apache-2.0，仓库指向 LogicFlow
- 判断：大概率是对 LogicFlow 的“企业内镜像/定制包命名空间”
- 可否修改：
  - 从许可证看可修改
  - 但若该包由公司私有源维护，实际发布与版本管理权限受组织流程约束

### 4.2 关键页面组件可改性结论
- 页面中大部分“关键业务组件”（如 `src/views/plan-simulation-modeling/components/**`）是**你方项目源码**，可直接改。
- 外部依赖组件（Element Plus / LogicFlow 等）可改，但建议优先级：
  1) **业务层封装扩展**（首选）
  2) **patch-package 定点补丁**（次选）
  3) **fork 并锁定版本**（最后手段）

---

## 5. 风险与建议

### 5.1 主要风险
1. **自定义图元代码量大，升级成本高**
   - LogicFlow 主版本升级可能影响自定义节点/边行为
2. **双命名空间 LogicFlow 依赖并存**
   - `@logicflow/*` 与 `@helinda-test-logicflow/*` 并存，需防止能力重复或行为不一致
3. **历史版本目录较多（an-old-version）**
   - 维护与排查时容易引入混淆

### 5.2 建议动作（可执行）
1. 建立“关键依赖白名单 + 许可证台账”（MIT/Apache-2.0）
2. 对 LogicFlow 的自定义扩展抽一层 adapter，降低升级耦合
3. 清理或冻结 old-version 目录，避免新旧逻辑交叉
4. 针对生产控制与属性面板建立组件测试（快照 + 交互）

---

## 6. 最终结论
- 前后端功能匹配度高：前端负责“图形化建模与配置”，后端负责“仿真核心与业务支撑 API”。
- 前端关键组件从许可证层面看**基本均为开源且可修改**（MIT / Apache-2.0）。
- 需要重点管理的是：
  1) LogicFlow 定制扩展的长期可维护性
  2) 私有命名空间包（`@helinda-test-logicflow/*`）的发布流程与版本控制策略

结论：**可改、能改、建议以封装+补丁为主，fork 为兜底策略。**