产业服务超市一期技术方案
采用 Vue 前端与 Spring Boot 后端，按业务模块组织一个后端应用。先支持稳定的服务券业务流程、权限隔离和数据留痕，再按实际需要扩展服务品类与外部接口。
01 技术选型与版本原则
前端建议 Vue 3、TypeScript、Vite、Vue Router、Pinia；后台管理界面可选 Element Plus。企业端采用适配桌面与手机浏览器的页面。原型使用本地打包的 Vue 3.5.22 浏览器版，无外部网络依赖。
后端采用 Spring Boot、Spring Security 和团队熟悉的持久层方案。数据库建议 MySQL，使用迁移脚本管理结构；附件优先使用现有对象存储或受控文件服务。Redis 仅在已有部署或确有缓存、会话需求时引入，不作为订单正确性的唯一保障。
Spring Boot 的具体主版本、JDK 与依赖版本需在核对旧项目和部署环境后锁定，不直接照搬未知旧版本。官方当前文档说明其 JDK 下限，最终选型仍要核对对应版本兼容矩阵和维护状态。当前工作目录没有旧项目代码，因此本方案尚未完成旧项目适配验证。
官方参考：Vue https://vuejs.org/guide/introduction ；Spring Boot https://docs.spring.io/spring-boot/system-requirements.html 。版本核对日期 2026 年 11 月 6 日。
02 总体架构
浏览器通过 HTTPS 访问 Nginx，Nginx 提供前端静态文件并将 /api 请求转发到 Spring Boot。后端访问业务数据库和附件存储，外部平台通过适配模块连接。生产数据库与文件源地址不直接开放给企业用户。
建议采用模块化单体：一个后端部署单元，代码内分开企业、服务、券、订单、交付、结算、审计和对接模块。避免一期引入分布式事务和复杂微服务运维；后续可按稳定模块边界逐步拆分。
见流程图册中的“技术架构图”。身份认证优先复用现有平台；若不能复用，需确认自有账号方案、企业成员管理和账号找回责任。
03 模块与数据边界
| 模块 | 职责 | 关键数据 |
|---|---|---|
| 企业与权限 | 企业资料、核验状态、成员及资格标签 | enterprise、enterprise_member、qualification |
| 服务与供应商 | 产品、价格版本、服务标准、入库结果 | service_product、supplier、supplier_document |
| 申请与审核 | 申请、补充、审核、公示与异议记录 | service_application、review_record、publicity_record |
| 服务券 | 发放、额度账本、有效期及使用范围 | voucher、voucher_ledger |
| 订单与交付 | 订单快照、交付凭证、企业确认及争议 | service_order、delivery_record、confirmation |
| 结算 | 结算申请、审核、付款结果及对账 | settlement、payment_record |
| 资料与审计 | 受控文件、动作日志、导出记录 | attachment、audit_log、export_job |
| 外部对接 | 单点登录、目录同步及重试 | external_mapping、integration_job |
04 关键数据设计
所有业务记录使用不可变主键和对外业务编号，保留创建时间、修改时间及业务归属。服务订单保存下单时产品名称、计价规则、合同版本、交付标准、供应商和抵扣金额快照，后续目录更新不改变已成立订单。
金额以数据库 DECIMAL 或整数分存储，接口统一明确单位；不得用浮点数直接核算。券账本按发放、冻结、释放、核销、冲正追加记录，不删除原始账目。原始额度 = 可用 + 冻结 + 已核销 + 已失效（考虑经审批的调整后核对）。
核心关联为企业 1:N 申请、申请 1:N 审核、申请 1:N 券、券 1:N 账本、订单 N:1 券、订单 1:N 交付。正式一期建议一笔订单使用一张券且只购买一个产品，拆单和多券合用留待业务明确后扩展。
结算和付款分别建模：一笔结算可以对应多次付款记录，但累计支付不得超过审核金额；业务取消或纠错通过独立冲正和审批流程完成。
05 状态与额度控制
| 对象 | 主流程 | 异常与约束 |
|---|---|---|
| 申请 | 草稿 → 待审核 → 公示中 → 可发券 → 已发券 | 退回补充后重新审核；公示异议未关闭不发券 |
| 券 | 可用 → 部分冻结或核销 → 用尽或到期 | 状态之外独立记余额；到期未用额度失效，已冻结订单按规则处理 |
| 订单 | 待接单 → 服务中 → 待确认 → 已确认待结算 → 已完成 | 待接单可取消并释放；服务中取消、部分交付走运营协调审批 |
| 交付 | 待提交 → 待企业确认 → 已确认 | 企业可退回补充，不自动确认或自动核销 |
| 结算 | 待提交 → 待审核 → 待支付 → 部分支付或已支付 | 退回补充；实际到账或付款回执核对后标记支付完成 |
06 关键事务和防重复处理
下单时，在同一数据库事务内校验企业归属、资格、券有效期、服务范围和余额；原子冻结额度、创建订单及账本。可使用版本号或带余额条件的 UPDATE，并检查受影响行数。并发失败返回明确提示，不能生成无额度支撑的订单。
下单、发券、确认和付款登记均接受幂等键，数据库对业务幂等键设置唯一约束。同一请求重试返回原结果；不同请求仍要通过余额和状态校验。
企业确认交付时，校验订单状态与企业身份，同一事务将冻结额度转为核销额度，并产生待结算记录。付款登记独立校验审批结果、累计金额及回执唯一性，不因生成结算单就标记已支付。
外部调用不得长期占用本地数据库事务。需要可靠通知时采用事务内事件表与后台重试任务，失败可查、可补偿；不得把接口超时当作已成功。
07 接口草案
| 接口 | 用途 | 必要约束 |
|---|---|---|
| GET /api/v1/services | 查询已发布服务 | 公开字段与后台字段分开 |
| POST /api/v1/applications | 提交申请 | 企业归属、必填资料、幂等键 |
| POST /applications/{id}/review | 审核或退回 | 岗位权限、状态、理由、版本号 |
| POST /applications/{id}/publicity-close | 结束公示并记录结果 | 期限满足、异议处理、操作凭证 |
| POST /applications/{id}/issue | 发券 | 额度授权、资金规则、不可重复发放 |
| POST /api/v1/orders | 使用服务券下单 | 服务范围、余额、冻结、幂等键 |
| POST /orders/{id}/delivery | 提交交付成果 | 供应商归属、受控附件 |
| POST /orders/{id}/confirm | 企业确认并核销 | 企业归属、交付版本及状态 |
| POST /settlements/{id}/payments | 登记实际付款结果 | 财务岗位、审批、金额和回执 |
| GET /api/v1/settlements/export | 导出结算资料 | 数据范围、脱敏、导出留痕 |
08 权限与附件安全
正式权限同时检查角色和数据归属。企业只读写本企业记录；供应商只能操作自己承接的订单；审核人员和财务人员按授权范围处理；系统管理员管理账号权限，不默认具备业务审批权。页面按钮隐藏不能替代后端鉴权。
公示仅展示获准公开的字段，不直接暴露联系人、证件、银行账户或完整申请材料。附件检查类型、大小和恶意内容，存储区不允许任意执行；下载通过授权接口或短期签名地址，上传和下载均留痕。
日志记录操作者、时间、对象、动作、前后状态、理由和请求编号，屏蔽令牌和敏感正文。演示中的浏览器存储不具备生产安全和审计能力。
09 部署与运行
划分开发、测试、生产环境，配置与密钥分离。通过前端构建包、后端 JAR、数据库迁移脚本和版本清单发布；上线前备份，失败按明确版本回滚。数据库迁移需考虑向后兼容，不能只回滚代码而忽略结构变化。
数据库和附件都纳入备份，按业务方确认的恢复目标制定周期并做恢复演练。监控请求错误、响应时长、券账本差额、卡住的订单、对接失败与存储容量；对账任务定期核对券、订单、核销和付款记录。
初始服务器规格与并发指标在用户规模、部署资源及附件量明确后，通过压测确定。本方案不对未经验证的并发量作承诺。
10 验证与验收重点
重点验证跨企业越权、供应商越权、重复发券、并发下单超额、过期券使用、重复确认、重复付款、公示异议阻断、交付退回、取消额度恢复、附件权限及恢复演练。
业务验收须使用测试企业演练后再开展真实试点；真实发券、合同和资金具备条件后，才计入年底业务成果。原型验收、软件验收、实际服务交付和财政结算分别留记录。
编制依据：2026 年 11 月 6 日的实施汇报与本次沟通。服务范围按最新“5 项核心服务＋2 类重点试点”表述。业务规则、真实接口及资金状态以业务方确认结果为准。