赵忠林
4a8b0a957c
- 在环境变量中新增CMS接口URL配置项 VITE_CMS_API_URL - 将所有CMS相关API接口调用的基地址由MODULES_API_URL或SERVER_API_URL替换为CMS_API_BASE_URL - 更新cmsAd、cmsAdRecord、cmsArticle及相关cms模块的接口地址引用 - 统一管理CMS API基础路径，提高代码维护性和可配置性
74 lines
6.1 KiB
Markdown
74 lines
6.1 KiB
Markdown
# 桂礼序 CMS 模块复用方案分析
|
||
|
||
> 分析对象：`mp-java`（modules 服务，cms 235 类） vs `guilixu-java`（桂礼序主后端，cms 152 类）
|
||
> 分析日期：2026-07-25
|
||
|
||
## 一、现状事实（已核实）
|
||
|
||
| 维度 | mp-java | guilixu-java |
|
||
|------|---------|--------------|
|
||
| 形态 | 单体 Spring Boot 应用（单 pom，@MapperScan `com.gxwebsoft.**`） | 同左 |
|
||
| cms 类数 | **235**（controller 37） | **152**（controller 25） |
|
||
| cms 数据库 | `modules` 库 | `db_guilixu`（prod/dev）、`modules`（test） |
|
||
| cms 建表/迁移 | 由 `src/main/java/com/gxwebsoft/cms/sql/` + `docs/sql` 管理，高频更新 | `sql/` 目录**无 cms 建表脚本** |
|
||
| git 引入时间 | 2025-07-24（"2.0版本分离"），持续开发 | 2026-06-01（"桂礼序"），已落后 ~1.5 个月 |
|
||
| 最近提交 | 2026-07-24/25（仍在改 cms） | 最近为 shop/order 相关，cms 停滞 |
|
||
|
||
**关键证据：**
|
||
|
||
1. **guilixu-java 的 152 个 cms 类，全部能在 mp-java 的 cms 里找到同名类**；mp-java 额外多出 83 个（CmsApp / CmsBanner / CmsCase 等系列）。→ guilixu 的 cms 是 mp-java cms 的**子集分叉**。
|
||
2. **前端（guilixu-admin）的 cms 接口早已使用 `MODULES_API_URL`**，路径如 `MODULES_API_URL + '/cms/cms-ad/page'`。`MODULES_API_URL` = `localStorage.ApiUrl || VITE_API_URL`，即指向 modules 服务（mp-java）。shop 的商户/优惠券接口同样走 `MODULES_API_URL`。→ **前端本就假定 cms/shop 由 mp-java 提供，guilixu-java 自己的 cms 包前端并不调用（重复/死代码）。**
|
||
3. **mp-java 与 guilixu-java 的 cms 控制器路径完全一致**（`/api/cms/cms-ad`、`/api/cms/cms-article-like` …），说明两者是同一套接口契约。
|
||
4. **完整复制不可编译**：mp-java 完整 cms 的 `CmsApp*`/`CmsWebsiteService*` 依赖 `com.gxwebsoft.project`（Project/ProjectService），而 guilixu-java **没有 project 模块**。把 235 类整体搬过去会编译失败。
|
||
|
||
## 二、方案对比
|
||
|
||
### 方案 A：guilixu 直接调用 mp-java 的 cms（modules 服务作为 cms 提供方）
|
||
|
||
**优点**
|
||
- ✅ 单一事实来源：cms 逻辑只维护一份，guilixu 永远拿到最新功能（含 83 个新增类）。
|
||
- ✅ 前端几乎零改动：guilixu-admin 的 cms 接口**已经**指向 `MODULES_API_URL`，契约路径与 mp-java 一致。
|
||
- ✅ 消除重复：可删除 guilixu-java 里 152 个冗余 cms 类，降低维护与同步负担。
|
||
- ✅ cms 数据/建表/迁移由 mp-java 集中管理（modules 库），guilixu 无需自建 cms 表。
|
||
- ✅ 符合现有"主后端 + modules 服务"双基地址架构（shop 已实现）。
|
||
|
||
**缺点 / 风险**
|
||
- ⚠️ 运行期耦合：guilixu 的 cms 功能可用性依赖 mp-java 在线（mp-java 宕机/升级 → cms 不可用）。
|
||
- ⚠️ 跨库一致：cms 在 `modules`，guilixu 业务在 `db_guilixu`；若需"同事务写 cms+shop"无法用本地事务，需走事件/Saga。
|
||
- ⚠️ 鉴权边界：mp-java 与 guilixu 各自用户体系（不同库），需确保 modules 服务对 guilixu-admin 的 cms 调用有合法鉴权（现有 TENANT_ID/APP_SECRET/ApiUrl 机制应已覆盖）。
|
||
- ⚠️ 接口微小差异：guilixu 是旧分叉，个别字段/路径若 mp-java 已重构，需对一遍（如 CmsWebsite 已删手机号脱敏方法）。
|
||
|
||
### 方案 B：把 cms 模块整个复制到 guilixu-java
|
||
|
||
**优点**
|
||
- ✅ 自包含：cms 随 guilixu-java 独立运行，不依赖 mp-java 在线。
|
||
- ✅ 接口契约稳定：沿用现有 guilixu-java cms 路径，前端无需改 baseURL。
|
||
- ✅ 可做 guilixu 专属深度定制，不受 mp-java 限制。
|
||
|
||
**缺点 / 风险**
|
||
- ❌ **语义上"整个复制"不可行**：完整 235 类依赖 guilixu 没有的 `project` 模块，编译失败；只能裁剪到子集，等于失去"完整"意义。
|
||
- ❌ 固化分叉：现在已落后 83 类/1.5 个月；mp-java cms 仍高频演进，复制后会陷入"复制→分叉→再复制"循环，双份维护成本最高。
|
||
- ❌ 数据迁移：需把 cms 表从 `modules` 迁到 `db_guilixu`，并自补建表/迁移脚本（目前 guilixu 无 cms 建表脚本）。
|
||
- ❌ 与前端现状冲突：前端 cms 调的是 `MODULES_API_URL`（mp-java），复制后这套 guilixu cms 实际无人调用（死代码），反而制造两套真相。
|
||
|
||
### （补充）方案 C：抽独立 cms 共享库/微服务（长期最优，成本高）
|
||
把 cms 抽成 `cms-spring-boot-starter`（或独立 cms 微服务 + 客户端 SDK），mp-java 与 guilixu-java 都依赖。能根治重复与分叉，但需重构打包、版本发布流程，短期落地成本高于 A。
|
||
|
||
## 三、结论与落地建议
|
||
|
||
**结论：选方案 A（guilixu 直接调用 mp-java 的 cms），不要整体复制到 guilixu-java。**
|
||
|
||
理由（按重要性）：
|
||
1. 前端早已按"modules 服务（mp-java）提供 cms"设计（cms 接口全走 `MODULES_API_URL`，路径契约一致）——方案 A 是顺延既有架构，方案 B 反而与现状冲突。
|
||
2. guilixu 的 cms 是 mp-java 的旧分叉子集且前端不调它，复制/扩展只会把分叉永久化；"整体复制"还因缺 `project` 模块无法编译。
|
||
3. cms 数据、建表、迁移本就在 mp-java（modules 库）集中管理，远程调用天然复用。
|
||
|
||
**落地步骤建议：**
|
||
1. 确认 `guilixu-admin` 的 `MODULES_API_URL` / `localStorage.ApiUrl` 指向 mp-java 部署实例（modules 服务），cms 调用即生效（前端基本不用动）。
|
||
2. **删除 guilixu-java 中重复的 `com/gxwebsoft/cms` 包（152 类）**，消除死代码与未来同步负担。
|
||
3. 对一遍 mp-java 与 guilixu 旧 cms 的接口字段差异（重点 CmsWebsite 等已重构类），确保前端无误。
|
||
4. 明确可用性边界：在运维/部署文档标注"cms 依赖 modules 服务"，并为 mp-java 配置高可用/健康检查。
|
||
5. 若后续确实需要 guilixu 专属、与自身业务同事务的 cms 能力，再走方案 C（抽共享库），不要走方案 B。
|
||
|
||
> 备注：若你的真实诉求是"让 guilixu 完全独立、不依赖 mp-java 在线"，则需在方案 B 基础上额外补 `project` 模块依赖 + cms 表迁移到 `db_guilixu` + 长期同步机制，综合成本最高，除非有强隔离需求否则不推荐。
|