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基础路径，提高代码维护性和可配置性

docs/cms-module-reuse-analysis.md

@@ -0,0 +1,73 @@
+# 桂礼序 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` + 长期同步机制，综合成本最高，除非有强隔离需求否则不推荐。