gxwebsoft
2b69686795
- 新增404页面，优化未找到页面体验，避免被搜索引擎索引 - 增加文件代理接口，隐藏真实文件服务器地址，支持文件请求代理 - 实现/article、/case、/product及/page动态路由兼容列表与详情展示 - 添加动态CMS页面兼容入口处理旧式路径，统一路由与SEO设置 - 新增模板1、模板7、模板2、模板3关于我们页面，实现多模板支持 - 模板增强支持CMS单页内容加载及SEO信息动态设置 - 配置环境变量及Git忽略文件规则辅助开发和构建环境管理
7.6 KiB
汇吉采「标书购买」后端选型评估：复用 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（单独启用）
- 它是 cms-api 的裁剪分支：源码包只有 payment+shop+common，没有 cms 内容接口。而标书项目列表前端要从 cms-api 取内容（导航/站点/权限），若订单在 guilixu-java，就出现「内容在 A 库、交易在 B 库」的跨库一致性问题。
- 独立数据库：
db_guilixu与modules不同机不同库，供应商账号、标书、订单若放 guilixu-java，与 cms-api 里的租户/内容无法天然关联，要额外做跨服务同步。 - 前端要新增对接：模板当前不认识 guilixu-java，需加代理路由 + baseURL + 租户/JWT 透传，工作量与风险都更高。
- 重复造轮子：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/detailPOST /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. 需要你拍板/确认
- 生产拓扑：汇吉采生产到底连的是 cms-api，还是 guilixu-java（shop-api）？从模板对接关系看是 cms-api，请确认（决定单后端还是双后端）。
- 供应商账号：复用现有 shop 用户体系（加 supplier 角色/字段），还是新建独立供应商表？建议前者，省一套登录态。
- 标书建模：当「特殊商品」复用 ShopGoods，还是新建 Tender 实体？建议新建 Tender，语义清晰、不污染商城商品。
- 微信商户号：cms-api 的微信支付配置（
resources/wechat/<tenantId>）是否已为该租户（10626）配好商户号与notify_url公网回调？
7. 一句话给老板
后端不用另起炉灶——
cms-api已经把「会员 + 商品 + 订单 + 微信扫码支付 + 异步回调 + 多租户」全备齐了，标书购买本质是在它里面加一个「标书」业务包 + 编排现有支付链路，前端再配一套购买流程页即可闭环。