gxwebsoft
2b69686795
- 新增404页面，优化未找到页面体验，避免被搜索引擎索引 - 增加文件代理接口，隐藏真实文件服务器地址，支持文件请求代理 - 实现/article、/case、/product及/page动态路由兼容列表与详情展示 - 添加动态CMS页面兼容入口处理旧式路径，统一路由与SEO设置 - 新增模板1、模板7、模板2、模板3关于我们页面，实现多模板支持 - 模板增强支持CMS单页内容加载及SEO信息动态设置 - 配置环境变量及Git忽略文件规则辅助开发和构建环境管理
95 lines
7.6 KiB
Markdown
95 lines
7.6 KiB
Markdown
# 汇吉采「标书购买」后端选型评估：复用 guilixu-java 还是 cms-api 新增？
|
||
|
||
> 阶段：**仅评估，未改动任何代码。**
|
||
> 上一轮已确认：标书购买 = 前端流程页（website-template）+ 后端账号/订单/支付。本轮聚焦「后端落哪」。
|
||
|
||
## 0. 结论（先说）
|
||
|
||
**建议在 `cms-api`（即 `cms-java-code`）里新增标书购买功能，复用其已有的 shop 订单 + payment 微信扫码支付底座；不单独启用 `guilixu-java`。**
|
||
|
||
理由一句话：`cms-api` 是模板**当前就在对接**的后台，且它**已经自带**商城（商品/订单/会员）、支付（微信 Native 扫码、`codeUrl` 返回、异步回调）、多租户（`TenantId`）——标书购买需要的后端能力它全有。`guilixu-java` 只是它的一个**裁剪分支**（只有 payment+shop+common，无 cms），且与 cms-api **独立部署、独立数据库**，单独启用反而要新增前端对接 + 双库一致性的成本。
|
||
|
||
---
|
||
|
||
## 1. 两个后端的真实身份（已查代码确认）
|
||
|
||
| 维度 | `guilixu-java` | `cms-java-code`（即 cms-api） |
|
||
|---|---|---|
|
||
| Maven artifactId | `shop-api` | `com-gxwebsoft-modules`（`name=com-gxwebsoft-api`） |
|
||
| 业务包 | 仅 `payment` + `shop` + `common` | `cms` + `shop` + `payment` + `common` + 多个垂直业务包（enterprise/dormitory/project/oa/house/pwl…） |
|
||
| 是否含 CMS 内容接口 | **否**（无 cms-page/article/nav） | **是**（模板的 `/cms/cms-*` 全在这里） |
|
||
| 微信扫码支付 | 有 `WechatNativeStrategy` | 有 `WechatNativeStrategy`（返回 `codeUrl`） |
|
||
| 订单能力 | `ShopOrder` 等 | `ShopOrder` + `PaymentController.createPaymentWithOrder`（创建订单并发起支付） |
|
||
| 多租户 | `TenantId` 头 | `TenantId` 头（与模板传参一致） |
|
||
| 数据库 | `db_guilixu`@47.119.165.234 | `modules`@8.134.169.209 |
|
||
| 部署关系 | 独立部署 | 独立部署（与 guilixu-java 不同机不同库） |
|
||
|
||
**关键认知纠偏**：`cms-api` 不是「只有内容管理」的模块。它是完整 monolith，已内含 shop + payment，且 `WechatNativeStrategy` 与 `PaymentController` 的「创建订单并支付」逻辑可直接服务标书购买。
|
||
|
||
---
|
||
|
||
## 2. 模板到底连的是哪个后台？
|
||
|
||
- 模板 `server/api/*` 全部代理到 `modulesApiBase`（cms-api）。证据：`server/api/form/submit.post.ts` 调 `/cms/cms-contact-lead/submit`；`product/list`、`page/detail`、`article/*` 等全走 cms-api。
|
||
- 模板目前**没有任何指向 `guilixu-java` 的代理/配置**。
|
||
- 因此：在 cms-api 新增标书接口 → 前端**零新增对接**（同 base、同 `TenantId` 头、同 JWT 体系）。在 guilixu-java 做 → 必须新增一条 server/api 代理 + 新 baseURL + 处理跨服务的租户/JWT 传递。
|
||
|
||
---
|
||
|
||
## 3. 标书购买在 cms-api 里能复用什么（已查实）
|
||
|
||
| 标书购买环节 | cms-api 现成能力 | 复用方式 |
|
||
|---|---|---|
|
||
| 供应商账号 | `shop` 模块的会员/用户体系（`ShopUser`、登录态、JWT `JwtAuthenticationFilter`） | 供应商注册/登录走现有用户体系（或新增 supplier 角色/字段） |
|
||
| 标书项目数据 | `shop` 的 `ShopGoods`/`ShopGoodsCategory` | 标书可建模为「一类特殊商品」（带发售起止、标书状态字段），或新增 `Tender` 实体复用同一套 CRUD/分页/过滤骨架 |
|
||
| 下单 | `PaymentController.createPaymentWithOrder`：创建订单 + 发起支付，要求 `loginUser != null`、自动带 `tenantId` | 标书购买直接走此接口（订单类型=标书） |
|
||
| 扫码付费 | `WechatNativeStrategy`：调微信 Native 支付，返回 `codeUrl`（前端据此渲染二维码） | 复用，无需重写扫码逻辑 |
|
||
| 支付成功回调 | `PaymentNotifyController` + `WxPayNotifyService.handlePaymentNotify` | 复用，回调里把订单置「已支付」 |
|
||
| 标书交付 | 现有文件上传/存储（`server/api/file` 后端侧） | 支付成功后按订单关联的文件下发/邮件 |
|
||
|
||
**也就是说：从「建订单 → 微信扫码 → 异步回调置已支付 → 交付」这条主链路，cms-api 已经闭环，标书购买主要是「数据建模 + 流程编排 + 前端页面」，而不是从零造支付。**
|
||
|
||
---
|
||
|
||
## 4. 为什么不选 guilixu-java（单独启用）
|
||
|
||
1. **它是 cms-api 的裁剪分支**：源码包只有 payment+shop+common，没有 cms 内容接口。而标书项目列表前端要从 cms-api 取内容（导航/站点/权限），若订单在 guilixu-java，就出现「内容在 A 库、交易在 B 库」的跨库一致性问题。
|
||
2. **独立数据库**：`db_guilixu` 与 `modules` 不同机不同库，供应商账号、标书、订单若放 guilixu-java，与 cms-api 里的租户/内容无法天然关联，要额外做跨服务同步。
|
||
3. **前端要新增对接**：模板当前不认识 guilixu-java，需加代理路由 + baseURL + 租户/JWT 透传，工作量与风险都更高。
|
||
4. **重复造轮子**：guilixu-java 的 shop/payment 与 cms-api 同源同构，单独跑一份只会增加部署与维护成本。
|
||
|
||
> 例外情况：若汇吉采这个客户**实际生产就在用 guilixu-java（shop-api）作为交易后台**，且 cms-api 只是内容源，则需改为「cms-api 出内容 + guilixu-java 出交易」的双后端方案。但这需要你确认生产部署拓扑——从代码与模板对接关系看，模板只连 cms-api，所以默认推荐单后端（cms-api）。
|
||
|
||
---
|
||
|
||
## 5. 推荐落地（在 cms-api 内新增）
|
||
|
||
新增一个独立业务包（参照现有 `shop`/`enterprise` 分包方式，如 `com.gxwebsoft.tender` 或归入 `shop`），包含：
|
||
|
||
- 实体：`Tender`（标书项目：招标编号、发售起止、状态 onsale/ended、售价、关联文件）、`TenderOrder`（标书订单，复用订单支付链路）、可选 `SupplierProfile`（供应商扩展信息）。
|
||
- 接口：
|
||
- `GET /api/tender/list`（按 status=onsale + 分类/关键词筛选）
|
||
- `GET /api/tender/detail`
|
||
- `POST /api/tender/order`（创建标书订单 + 发起微信扫码支付，复用 `createPaymentWithOrder`）
|
||
- `POST /api/tender/notify`（微信异步回调，复用 `WxPayNotifyService`）
|
||
- `GET /api/tender/order/status`（前端轮询）
|
||
- `GET /api/tender/order/download`（支付后下载标书，登录态 + 订单校验）
|
||
- 供应商账号：复用现有用户体系（注册/登录/JWT），在「购买入口」做登录态门控（前端）+ 下单接口要求 `loginUser != null`（后端，已有）。
|
||
|
||
前端（website-template）配合：激活 `buy` 入口（照搬 renewal）、`BuyDocument` 改为购买流程页、注册/登录页 + `useSupplier` 登录态、对接上面 5~6 个新接口。
|
||
|
||
---
|
||
|
||
## 6. 需要你拍板/确认
|
||
|
||
1. **生产拓扑**：汇吉采生产到底连的是 cms-api，还是 guilixu-java（shop-api）？从模板对接关系看是 cms-api，请确认（决定单后端还是双后端）。
|
||
2. **供应商账号**：复用现有 shop 用户体系（加 supplier 角色/字段），还是新建独立供应商表？建议前者，省一套登录态。
|
||
3. **标书建模**：当「特殊商品」复用 ShopGoods，还是新建 Tender 实体？建议新建 Tender，语义清晰、不污染商城商品。
|
||
4. **微信商户号**：cms-api 的微信支付配置（`resources/wechat/<tenantId>`）是否已为该租户（10626）配好商户号与 `notify_url` 公网回调？
|
||
|
||
---
|
||
|
||
## 7. 一句话给老板
|
||
|
||
> 后端不用另起炉灶——`cms-api` 已经把「会员 + 商品 + 订单 + 微信扫码支付 + 异步回调 + 多租户」全备齐了，标书购买本质是在它里面**加一个「标书」业务包 + 编排现有支付链路**，前端再配一套购买流程页即可闭环。
|