业务和功能介绍
宠主免费发布托运需求，缴纳履约保证金的托运商家在线报价，宠主比价后选择商家；平台向成交商家收取订单技术服务费，托运费用由宠主和商家线下自行结算。平台不参与实际的运输过程，规避法律风险并提高运营稳定性！
项目实现
1. 整体框架与设计思路
核心是做一个“双边竞价撮合”平台。业务主线明确：C端发单 -> B端交保证金 -> B端竞价 -> C端比价决定 -> 平台抽佣。
设计思路上，为了快速跑通业务，系统划分为三大核心模块：宠主端（重表单提交与比价交互）、商家端（重抢单效率与消息通知）、运营后台（重抽佣财务对账）。交易逻辑上采用“平台抽佣 + 尾款线下结算”分离的模式，既保证了平台的盈利点，又大幅降低了平台的资金监管和合规风险。
2. 核心技术栈
前端（小程序端）：微信原生开发 + TDesign 组件库（契合轻量化落地，UI一致性好，开发提效）。
后端服务：Node.js / Spring Boot + MySQL（处理订单和关系型数据）。
缓存与中间件：Redis（应对高频的比价大厅刷新和抢单并发控制）。
3. 我的职责与量化结果
核心链路开发：负责“发单-报价-比价-成交”核心交易链路的前端UI实现与后端接口对接。
性能优化：重构了“比价大厅”的长列表数据加载逻辑，通过接口数据聚合和字段精简，将核心页面首屏加载时间从 2.8s 压降至 1s 以内。
业务保障：系统上线后，成功支撑日均 500+ 次的商家并发报价请求，核心接口报错率控制在 0.1% 以下，宠主从发单到收到首个报价的平均等待时间缩短至 10 分钟。
4. 遇到的坑与解决方案
坑1：高并发导致重复报价与状态异常
难点：热门单子一发布，多个商家同时抢单报价，或者单一商家网络卡顿连续点击，导致数据库插入重复报价。
解决：放弃单纯依赖前端防抖，在后端引入 Redis 分布式锁。提交报价时以 需求ID + 商家ID 生成唯一锁，确保核心扣减和写入逻辑的原子性与接口幂等性。
坑2：履约保证金支付状态偶尔“丢失”
难点：强依赖微信支付的异步回调，遇到网络抖动时，商家付了保证金，但系统里状态没更新，导致无法报价，引发客诉。
解决：不能单点依赖回调。增加了“主动查询+对账兜底”机制：前端支付成功后主动轮询后端，后端实时调用微信查单接口同步状态；配合后台定时任务扫表对账，彻底解决状态不一致问题。
坑3：复杂比价列表导致前端内存暴涨掉帧
难点：宠主比价时，列表里包含大量商家头像、宠物实拍图以及长篇幅的“服务详情”，导致小程序滑动卡顿。
解决：对数据接口进行“瘦身”，将复杂的“服务详情”富文本剥离为按需懒加载；同时对接云端 OSS 对图片进行带参数的缩略图处理，极大降低了内存占用，列表滑动帧率稳在 60fps。
核心是做一个“双边竞价撮合”平台。业务主线明确：C端发单 -> B端交保证金 -> B端竞价 -> C端比价决定 -> 平台抽佣。
设计思路上，为了快速跑通业务，系统划分为三大核心模块：宠主端（重表单提交与比价交互）、商家端（重抢单效率与消息通知）、运营后台（重抽佣财务对账）。交易逻辑上采用“平台抽佣 + 尾款线下结算”分离的模式，既保证了平台的盈利点，又大幅降低了平台的资金监管和合规风险。
2. 核心技术栈
前端（小程序端）：微信原生开发 + TDesign 组件库（契合轻量化落地，UI一致性好，开发提效）。
后端服务：Node.js / Spring Boot + MySQL（处理订单和关系型数据）。
缓存与中间件：Redis（应对高频的比价大厅刷新和抢单并发控制）。
3. 我的职责与量化结果
核心链路开发：负责“发单-报价-比价-成交”核心交易链路的前端UI实现与后端接口对接。
性能优化：重构了“比价大厅”的长列表数据加载逻辑，通过接口数据聚合和字段精简，将核心页面首屏加载时间从 2.8s 压降至 1s 以内。
业务保障：系统上线后，成功支撑日均 500+ 次的商家并发报价请求，核心接口报错率控制在 0.1% 以下，宠主从发单到收到首个报价的平均等待时间缩短至 10 分钟。
4. 遇到的坑与解决方案
坑1：高并发导致重复报价与状态异常
难点：热门单子一发布，多个商家同时抢单报价，或者单一商家网络卡顿连续点击，导致数据库插入重复报价。
解决：放弃单纯依赖前端防抖，在后端引入 Redis 分布式锁。提交报价时以 需求ID + 商家ID 生成唯一锁，确保核心扣减和写入逻辑的原子性与接口幂等性。
坑2：履约保证金支付状态偶尔“丢失”
难点：强依赖微信支付的异步回调，遇到网络抖动时，商家付了保证金，但系统里状态没更新，导致无法报价，引发客诉。
解决：不能单点依赖回调。增加了“主动查询+对账兜底”机制：前端支付成功后主动轮询后端，后端实时调用微信查单接口同步状态；配合后台定时任务扫表对账，彻底解决状态不一致问题。
坑3：复杂比价列表导致前端内存暴涨掉帧
难点：宠主比价时，列表里包含大量商家头像、宠物实拍图以及长篇幅的“服务详情”，导致小程序滑动卡顿。
解决：对数据接口进行“瘦身”，将复杂的“服务详情”富文本剥离为按需懒加载；同时对接云端 OSS 对图片进行带参数的缩略图处理，极大降低了内存占用，列表滑动帧率稳在 60fps。
示例图片视频
相似推荐
粮食收购点出入口系统-粮食收购点出入口系统
1.为了乡镇粮食收购点的业务功能如：出入库、记录库存、统计查询使用方便
2.满足多个收购点多租户登录使用
3.满足多个品种地磅进行系统适配使用
4.满足多个品牌摄像头接入
5.能够进行实时小票打印，包含销售模块、收购模块，能够根据小票的二维码快速查询信息
富络wms-物流仓储管理系统
面向物流仓储行业的企业级仓储管理平台，实现收货入库、出库拣货、库内调拨、库存盘点、批次管理、条码打印、仓储看板全链路业务闭环，支持多仓库、多货主模式，与集团ERP系统打通数据互通，支撑多家线下物流仓日常作业。本人担任前端主程，统筹前端整体架构、任务分配、技术方案、代码质量与版本交付。
智能仓储 · 立库调度监控系统（RMS 调度中间件 + 监控管理后台）-RmsCC
【1】立项背景与目标
自动化立体库是新能源锂电、汽车零部件等行业的主流仓储形态，库内由四向车、提升机、输送线、接驳口协同完成托盘出入库。上游 WMS/WES 只下发"某个托盘要入库或出库"，而"分配到哪个货位、走哪条路、派哪台车、每一段由谁执行"全部由中间的调度系统（RMS）计算并驱动——本项目就是一个立库调度中间件 + 配套的调度监控管理后台。目标：把"任务下发→货位分配→路径规划→派车→分段执行→库存过账"做成可跑通、可观测、可人工干预的闭环，并解决现场最头疼的三个问题：调度计划与现场执行脱节、设备与货位状态不可见、故障（走不通、卡住）无日志可查。
【2】核心功能模块
①基础数据：仓库/货区/货位（层-x-y 坐标、深浅位）/设备/物料建模。
②权限体系：JWT + RBAC 用户-角色-菜单三级权限，菜单级与接口级双重校验。
③上游任务管理（内置 WES 模拟器）：批量下发出入库任务，一键生成托盘号。
④任务调度与分段：任务状态机（待下发/执行中/已完成/异常/取消），入库按固定拓扑自动拆 3 段（库外输送线→提升机→目标层接驳口→货位），出库镜像反向。
⑤路径规划：库内 A* 网格寻路（巷道四向可走、货架区仅纵向、有货货位视为障碍），按"空闲且电量>40% + 曼哈顿距离最近"自动派车，支持小车避让、等待点与自动移库（倒库）。
⑥设备仿真引擎：无真实 PLC，用定时任务按可配置节拍推进每段任务并驱动设备沿路径移动。
⑦实时监控：WebSocket 每秒推送设备位置、状态与任务进度，地图大屏显示库位占用与小车轨迹，另配小车/设备监控页。
⑧库存与数据中心：托盘维度库存、分层占用统计、库存流水（任务完成自动过账）。
⑨接口日志中心：按上游/RCS/WCS 三个通道记录每次调用的请求与返回报文、方向、结果、耗时，支持按托盘号/任务号全链路检索与改报文重发。
⑩AI 作业助手：接入大模型，自然语言下发任务、异常诊断与智能问答，SSE 流式输出，模型不可用自动降级为本地规则。
⑪单车手动控制：顶升/放下/移动/充电/恢复/释放任务等指令，应急时人工接管。
【3】业务流程与功能路径
上游下发（托盘号 + 出入库类型）→ RMS 自动分配货位（浅位优先、低层优先）→ 生成分段计划 → A* 计算路径并派最近的空闲车 → 仿真引擎按节拍推进各段 → 全段完成后自动过账（货位占用/释放、绑定或解绑托盘、写库存流水与系统日志）→ 任务归档。
功能路径：登录 → 首页看板（货位占用 + 任务趋势）→ 上游任务管理下发任务 → 资源监控中心地图大屏观察执行 → 立库任务中心（任务视图/任务管理）→ 数据中心查库存与流水 → 报表数据中心查接口日志 → AI 助手用自然语言下单。
库存订单及项目清单管理系统
业务目标：面向装修公司的硬软装材料库存+订单管理系统，据用库存档案、双类分类、采购入库、项目订单与材料清单(BOM)满足装修需求，进行汇总审核。 打通采购仓储、工地领用、成本核算整体链路；管理多个施工工地领料调拨，库管-采购-工头按角色各取所需，取用留存数据可追溯、可对账、可核算。
功能分块：管理系统包含库存与分类、采购入库、项目订单(材料清单)、领料出库、成本管理几大板块组成。避免硬软装混记，材料出入库无记录，多工地调拨导致库存和成本口径对不上项目利润算不清等痛点。
业务流程：维护材料库存(硬软装) -> 项目订单生成材料清单(追溯留痕) -> 库存校验按需采购 -> 领料出库调拨(扣减库存并归集到项目成本) -> 成本看板核算对账(理清出入库口径+损耗)。
文昌超级工厂
本项目服务卫星总装测试现场。计划、工艺、物料、检验和物流原来分散在不同系统，工位执行靠人工传递，结果不能及时回到工单上。立项目标是在制造执行平台上建成 MES：按工单、工序、工步组织作业，把仓储、试验检验和审批接进来，使任务可接收、过程可采集、结果可追溯。
核心功能分八块。一是基础数据，接收物料、设备、工具工装和制造 BOM。二是计划与工单，接收生产计划并按站点、工位下发。三是作业准备，包括人员资质、工艺附件、环境数据和设备点检。四是工序执行，覆盖开工、工步采集、物料装配与拆卸、工装和辅料、完工检查。五是检验回传，包括通用检验、力学、站点、热实验、电测和拍照声像，支持附件。六是仓储物流，包括叫料、配送、转运、入库、退库、临时补料、整星和工装出入库、空托盘回库。七是异常，现场填报确认，并接收环境系统异常。八是审批提醒，通过飞书卡片通知待办。
业务路径按一张工单走通：外部下发计划和 BOM 并生成工单；站点接收时若存在多个接驳位，先选定起点和终点，再向仓储下发配送或转运；准备完成后工序开工，工步采集并完成装配；试验或检验系统回传结果，关键检推送审批；完工前核对采集、物料、工装、辅料四类实绩；仓储回写执行结果后关闭物流任务。
帮助文档
Copyright @ 2021-2024 程聚宝 | 浙ICP备2021014372号
人工客服