业务和功能介绍
这个项目是一个基于若依二次开发的业务系统，整体采用经典的前后端分离架构：后端以 Spring Boot 2.5.x + MyBatis 为核心，前端使用 RuoYi-Vue 技术栈承载管理端页面与交互。代码结构延续若依多模块设计，根工程统一管理依赖与版本，按职责拆分为 ruoyi-admin（Web 入口）、ruoyi-framework（安全与框架能力）、ruoyi-system（系统管理能力）、ruoyi-common（通用组件）、ruoyi-quartz（定时任务）和 ruoyi-generator（代码生成）等模块，具备较好的工程化组织方式，便于按功能扩展和部署维护。
本项目的核心场景围绕“商品-下单-支付-履约-售后”形成完整闭环。控制层包含商品分类、商品管理、订单、子订单、购物车、售后、观演人、地址、轮播图、图文内容、表单等多个子域接口，同时提供面向微信端的聚合入口。业务命名和接口路径显示该系统兼具后台运营管理能力与微信侧用户服务能力，既支持后台对商品、内容、订单状态进行维护，也支持用户在微信端完成浏览、下单、支付、查询与售后申请等流程。
在核心交易链路上，订单服务实现了较完整的状态流转逻辑：下单前进行库存校验和扣减，生成主订单与子订单号，记录订单日志，结合 Redis 做待支付订单的超时控制，再通过支付回调推进支付状态与订单状态变更。支付模块集成微信支付能力，覆盖下单支付、回调验签处理、退款等关键路径；同时系统通过枚举类管理支付状态、订单状态与售后状态，提高了状态机可读性和一致性。
项目使用 MySQL 作为主数据存储，Druid 连接池管理数据库连接，Redis 承担缓存、会话态与部分业务状态存储；并集成 Redisson 用于分布式锁等并发控制场景。接口规范沿用若依体系的统一响应对象与分页对象，便于前后端协作和标准化返回。系统还保留了 Swagger、日志审计、权限控制、字典配置、定时任务等通用企业后台能力，具备较强的可运营性。整体上，这是一个以若依为底座、深度贴合微信业务流程的交易型管理系统，既继承了成熟后台框架的稳定性，也通过 mt 业务域实现了面向实际运营场景的功能落地。
本项目的核心场景围绕“商品-下单-支付-履约-售后”形成完整闭环。控制层包含商品分类、商品管理、订单、子订单、购物车、售后、观演人、地址、轮播图、图文内容、表单等多个子域接口，同时提供面向微信端的聚合入口。业务命名和接口路径显示该系统兼具后台运营管理能力与微信侧用户服务能力，既支持后台对商品、内容、订单状态进行维护，也支持用户在微信端完成浏览、下单、支付、查询与售后申请等流程。
在核心交易链路上，订单服务实现了较完整的状态流转逻辑：下单前进行库存校验和扣减，生成主订单与子订单号，记录订单日志，结合 Redis 做待支付订单的超时控制，再通过支付回调推进支付状态与订单状态变更。支付模块集成微信支付能力，覆盖下单支付、回调验签处理、退款等关键路径；同时系统通过枚举类管理支付状态、订单状态与售后状态，提高了状态机可读性和一致性。
项目使用 MySQL 作为主数据存储，Druid 连接池管理数据库连接，Redis 承担缓存、会话态与部分业务状态存储；并集成 Redisson 用于分布式锁等并发控制场景。接口规范沿用若依体系的统一响应对象与分页对象，便于前后端协作和标准化返回。系统还保留了 Swagger、日志审计、权限控制、字典配置、定时任务等通用企业后台能力，具备较强的可运营性。整体上，这是一个以若依为底座、深度贴合微信业务流程的交易型管理系统，既继承了成熟后台框架的稳定性，也通过 mt 业务域实现了面向实际运营场景的功能落地。
项目实现
在这个项目里，我整体采用的是“若依底座 + 业务域扩展”的思路。底层沿用若依多模块结构，把公共能力和业务能力拆开，避免把所有代码堆在一个工程里。技术上，后端是 Spring Boot + Spring MVC + MyBatis，数据库用 MySQL，缓存和状态控制用 Redis，并发控制场景引入了 Redisson。系统模块上，ruoyi-framework 负责安全、权限、拦截器、统一异常等基础能力；ruoyi-system 承担用户、角色、菜单、字典等通用管理；ruoyi-common 放工具类和公共封装；ruoyi-admin 作为接口入口承载具体业务；ruoyi-quartz 负责定时任务；ruoyi-generator 用于代码生成提效。前端是若依 Vue 体系，走前后端分离，后端只提供标准化 REST 接口。这种设计的核心目标是：基础能力稳定复用、业务模块快速迭代、线上问题可定位可追踪。
我自己主要负责的是 mt 业务域里的交易主链路，重点包括商品下单、购物车结算、微信支付回调、售后流程、订单状态流转和相关日志追踪。落地结果上，我完成并联调了订单/支付/售后相关核心接口链路，覆盖“创建订单-库存校验与扣减-待支付超时控制-支付回调改态-履约/提货-售后申请与审核”等关键环节；仅微信侧聚合接口就沉淀了 50+ 个，后台管理侧对应模块也全部打通，包含订单、子订单、售后、地址、观演人、商品等管理能力。业务稳定性上，我把订单状态和支付状态做了枚举化和分层处理，减少了“魔法值”带来的误改；把待支付订单放进 Redis 做超时控制后，明显减少了脏订单和超时未关闭带来的人工处理成本。项目推进方式上，我是按“接口先行 + 状态机兜底 + 日志可回放”来做，确保每次改动都能回溯。
项目里最难的点主要有三个。第一是交易状态一致性，尤其是“下单扣库存”和“支付回调改状态”之间的时序问题。早期踩过的坑是并发下单或重复回调导致状态覆盖，出现库存与订单不一致。我的处理是把关键状态流转前置校验、幂等判断和锁控制结合起来：库存操作集中收口、支付回调按订单号做幂等、只允许状态单向推进，同时把关键操作写入订单日志，出问题能快速还原现场。第二是金额精度问题，前后端传参和第三方支付对金额单位不一致，容易出现“元/分”混用。我统一采用“数据库存分、展示层转元”的策略，并在下单、回调、退款三条链路做统一转换，避免了对账差异。第三是微信支付和售后退款链路联动复杂，回调报文、验签、异常分支多，稍不注意就会造成“支付成功但本地状态未更新”或“退款结果未落库”。我把回调处理拆成“报文解析-结果校验-业务更新-日志记录”四步，出现异常时保证可重试、可补偿，并通过统一返回和告警日志降低排查成本。
我自己主要负责的是 mt 业务域里的交易主链路，重点包括商品下单、购物车结算、微信支付回调、售后流程、订单状态流转和相关日志追踪。落地结果上，我完成并联调了订单/支付/售后相关核心接口链路，覆盖“创建订单-库存校验与扣减-待支付超时控制-支付回调改态-履约/提货-售后申请与审核”等关键环节；仅微信侧聚合接口就沉淀了 50+ 个，后台管理侧对应模块也全部打通，包含订单、子订单、售后、地址、观演人、商品等管理能力。业务稳定性上，我把订单状态和支付状态做了枚举化和分层处理，减少了“魔法值”带来的误改；把待支付订单放进 Redis 做超时控制后，明显减少了脏订单和超时未关闭带来的人工处理成本。项目推进方式上，我是按“接口先行 + 状态机兜底 + 日志可回放”来做，确保每次改动都能回溯。
项目里最难的点主要有三个。第一是交易状态一致性，尤其是“下单扣库存”和“支付回调改状态”之间的时序问题。早期踩过的坑是并发下单或重复回调导致状态覆盖，出现库存与订单不一致。我的处理是把关键状态流转前置校验、幂等判断和锁控制结合起来：库存操作集中收口、支付回调按订单号做幂等、只允许状态单向推进，同时把关键操作写入订单日志，出问题能快速还原现场。第二是金额精度问题，前后端传参和第三方支付对金额单位不一致，容易出现“元/分”混用。我统一采用“数据库存分、展示层转元”的策略，并在下单、回调、退款三条链路做统一转换，避免了对账差异。第三是微信支付和售后退款链路联动复杂，回调报文、验签、异常分支多，稍不注意就会造成“支付成功但本地状态未更新”或“退款结果未落库”。我把回调处理拆成“报文解析-结果校验-业务更新-日志记录”四步，出现异常时保证可重试、可补偿，并通过统一返回和告警日志降低排查成本。
示例图片视频
相似推荐
政务服务平台-数图新治
【项目简介】
数图新治(简称：数图)是一个政务大数据分析平台，通过算法配置、图表数据展示、汇成专题来进行数据分析、数据挖掘、成果展
示，帮助决策。数图是一个核心产品，从该产品衍生一个个智慧统计项目，部署到各个项目地。到目前为止已服务了全国三四十个
街道办、地区统计局、区政府。
【功能点】
● 图表展示、图表下钻，用到 echarts 的大部分图表及高德地图，项目地涉及到一些客户要求的第三方地图；
●自动报告，用户点击图表生成语料并直接生成报告；用户可通过将语料、图表、图片等拖入到在线报告中，也可手动输入和增加
配置条件生成动静态文本来生成自动报告，如生成日报、周报、月报、季报、年报等；通过拖拽、富文本编辑实现
●自由页面配置，用户通过拖拉拽实现自由页面布局及页面内容展示，实现对页面框架、图表、资源框、筛选器等的功能配置和样
式配置等
● 支持全定制和半定制半配置的页面
●兼容，配置的专题在 pc 、大屏、pad 、移动端使用，实现四端兼容
●在线报表，通过配置实现自动生成报表，数据自动生成，在线编辑、保存、下载报表，通过 lucksheet 实现
●地图，实现各种类型地图如高德、百度、客户要求的第三方地图，涉及到的业务需求如落点、标牌、下钻、框选、热力图、白
模、3D、影像地图、二维地图、聚合、图上加 echarts 图表、弹框、色块、距离计算等
●文件下载，包括数据下载 excel ，图表下载成 word 文档、pdf 下载、报表下载等；
●文件上传，excel、txt、image、word、pdf等；
●文件预览，在线 word、pdf、excel 文档预览；
公安低空数智融合应用平台
主要面向公安局、巡特警反恐支队及各区县分局。适用于日常城市治安巡查、重点区域（公园、商场、交通枢纽）的常态化低空安防巡检、大型活动安保及突发事件的应急指挥调度，助力构建“地空立体化”的智慧警务防控体系。
重点车辆管控平台
重点车辆管控平台，基于AI能力，通过源头管控、车路联动等多种维度研判，对重点车辆违法行为进行抓拍，形成车辆画像，包括：无证运输、未苫盖车辆、道路遗撒、改装车、遮掩污损号牌等，为城市管理提供执法依据，实现执法闭环。
省级疾控健康管理平台-心血管预警与干预信息系统
服务于省级疾控中心，用于全省心血管疾病高危人群的早期筛查、风险预警和干预管理。系统覆盖全省各级基层医疗机构和疾控中心，核心业务流程包括：
基层医护人员通过系统对辖区内居民进行心血管健康评估，填写涵盖血压、血脂、血糖、吸烟史、家族史、既往病史等多维度的评估量表。系统根据评估数据自动计算心血管事件风险等级（低危/中危/高危），生成个性化干预方案（如用药建议、生活方式指导、定期随访提醒）。对高危人群建立长期随访档案，基层医护人员定期跟踪干预效果并更新健康数据。省级疾控中心汇总全省数据，进行心血管疾病负担分析、高危人群分布统计和防控策略制定。
系统需在微信生态中使用，医护人员通过微信公众号入口访问，进行病例上报和数据查询。因此URL必须干净、可分享，且用户通过微信消息点击链接后，需精确跳转到指定页面。系统还需支持多角色权限管理（基层医生、疾控审核员、省级管理员），不同角色对应不同的功能模块和数据视图。
省级疾控健康管理平台-老年疾病信息管理系统大框架（认知筛查子系统）
服务于省级疾控中心，面向全省基层医疗机构，用于老年人群的认知障碍筛查与健康管理。核心业务流程包括：基层医护人员通过系统对辖区内老年居民进行认知功能评估，填写标准化认知筛查量表（如MMSE、MoCA等国际通用量表及本土化量表）；系统根据量表得分自动判定认知障碍风险等级（正常/轻度/中重度），生成个性化随访建议；省级疾控中心汇总全省筛查数据，进行认知障碍患病率统计、流行病学分析和资源调配决策。
系统涉及多种认知筛查量表，每种量表包含数十个评估条目，且条目间存在复杂的联动规则：如某个条目得分异常时，需自动触发补充评估模块；不同年龄段、教育程度的受试者，其评分标准和风险阈值不同；量表填写过程中需实时校验数据的完整性和逻辑合理性。
帮助文档
Copyright @ 2021-2024 程聚宝 | 浙ICP备2021014372号
人工客服