Files

赵忠林 4a8b0a957c refactor(api): 统一CMS接口URL配置

- 在环境变量中新增CMS接口URL配置项 VITE_CMS_API_URL
- 将所有CMS相关API接口调用的基地址由MODULES_API_URL或SERVER_API_URL替换为CMS_API_BASE_URL
- 更新cmsAd、cmsAdRecord、cmsArticle及相关cms模块的接口地址引用
- 统一管理CMS API基础路径，提高代码维护性和可配置性

2026-07-27 12:42:51 +08:00

6.1 KiB

Raw Permalink Blame History

桂礼序 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 停滞

关键证据：

guilixu-java 的 152 个 cms 类，全部能在 mp-java 的 cms 里找到同名类；mp-java 额外多出 83 个（CmsApp / CmsBanner / CmsCase 等系列）。→ guilixu 的 cms 是 mp-java cms 的子集分叉。
前端（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 包前端并不调用（重复/死代码）。
mp-java 与 guilixu-java 的 cms 控制器路径完全一致（/api/cms/cms-ad、/api/cms/cms-article-like …），说明两者是同一套接口契约。
完整复制不可编译：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。

理由（按重要性）：

前端早已按"modules 服务（mp-java）提供 cms"设计（cms 接口全走 MODULES_API_URL，路径契约一致）——方案 A 是顺延既有架构，方案 B 反而与现状冲突。
guilixu 的 cms 是 mp-java 的旧分叉子集且前端不调它，复制/扩展只会把分叉永久化；"整体复制"还因缺 project 模块无法编译。
cms 数据、建表、迁移本就在 mp-java（modules 库）集中管理，远程调用天然复用。

落地步骤建议：

确认 guilixu-admin 的 MODULES_API_URL / localStorage.ApiUrl 指向 mp-java 部署实例（modules 服务），cms 调用即生效（前端基本不用动）。
删除 guilixu-java 中重复的 com/gxwebsoft/cms 包（152 类），消除死代码与未来同步负担。
对一遍 mp-java 与 guilixu 旧 cms 的接口字段差异（重点 CmsWebsite 等已重构类），确保前端无误。
明确可用性边界：在运维/部署文档标注"cms 依赖 modules 服务"，并为 mp-java 配置高可用/健康检查。
若后续确实需要 guilixu 专属、与自身业务同事务的 cms 能力，再走方案 C（抽共享库），不要走方案 B。

备注：若你的真实诉求是"让 guilixu 完全独立、不依赖 mp-java 在线"，则需在方案 B 基础上额外补 project 模块依赖 + cms 表迁移到 db_guilixu + 长期同步机制，综合成本最高，除非有强隔离需求否则不推荐。

6.1 KiB Raw Permalink Blame History Unescape Escape