java购物车实现流程—java购物车实现流程注意事项 收藏 0

经典电商购物车数据结构及实现过程

最近有购物车逻辑,涉及到购物车列表,这里说一下自己的实现方式,各位如果有更好的方式欢迎评论区留言.

1.与前端协定好的接口协议:

整体的结构解读:

商家基本信息(昵称 头像 id)

商品列表信息(goodsSpecInfoList)

商品1基本信息

规格具体信息(specContentInfos)

商品2基本信息

规格具体信息(specContentInfos)

2.具体实现的逻辑:

根据用户名查询购物车订单中的商家信息.然后查询每一个商家信息下面关联的商品规格信息,此处使用mybatis的collection标签.由于规格表中存储的是规格id与规格项id,所以根据规格id信息去规格项与规格表中查询了对应的规格名称与规格项名称.

3.dao接口:

4.dao映射配置文件(头文件以及命名空间已省略):

5.涉及到的实体类(省略get/set)

返回页面的购物车实体类:

购物车中商品规格基本信息:

规格参数实体类:

规格id组合实体类:

说明:GoodsCartReturnVo中包含GoodsSpecInfo,GoodsSpecInfo中包含SpecContentInfo

6.涉及到的表(测试数据参考):

购物车表:

商品规格表(spec_content存储规格id与规格项组成的json格式):

规格表(其他字段已忽略):

规格项表(其他字段已忽略):

7.逻辑层数据处理:

8.说明:由于goods_spec中的spec_content中存储的是规格id与规格项id的json字符串,所以需要调用findSpecContentInfo方法将对应的名称查询出来.

如果有所收获欢迎在评论区点赞和关注，持续输出原创实战文章！

一个Java版 Spring+Uniapp的开源商城项目

我所在的开发团队相对还是比较厉害的，在码云上曾经开源过一个PHP版的基于TP6.0+vue的开源商城项目，获得了不错的Start量，也有很多开发者参与进来一起完善这个项目，经过几年的维护目前已经相对非常稳定的项目，大大降低了大家二开造轮子的时间精力成本，随着项目的不断完善，有很多JAVA开发者就提出能不能用这个PHP版的架构再开源一个java版的商城系统，经过一众开发者的日夜辛劳，以及大家积极的反馈测试，今天终于可以通知大家，完成啦！开源啦！

所有的代码、文件全部都开源到 Gitee仓库中，并没有任何藏着掖着的行为，不会说缺少哪个页面或者某个重要功能，包括前后端的前端源码都开源在项目中，并且接口文档也非常细心的给大家打包进了项目，主要是为了方便大家能快速的上手及二次开发 当然，也希望感兴趣的朋友可以找找其中的问题，提一些 pr 或者 issue，让这个开源项目能够减少问题并且保持进步。

crmeb_java电商营销系统Gitee开源地址：

crmeb_php电商营销系统Gitee开源地址：

本项目已经部署到了线上供大家测试预览，相关移动端演示地址以及后台演示地址在开源仓库里可以看到。

备注：进入演示站点，为了方便大家测试，给的演示权限就是超管的权限，所以请大家不要随意改密码！请大家不要随意改密码！请大家不要随意改密码！

CRMEB商城JAVA版，SpringBoot + Maven + Swagger + Mybatis Plus + Redis + Uniapp +Vue 包含移动端、小程序、PC后台、Api接口；有产品、用户、购物车、订单、积分、优惠券、营销、余额、权限、角色、系统设置、组合数据、可拖拉拽的form表单等模块，大量的减少了二开的成本。

有详细的代码注释，有完整系统手册

SpringBoot框架

前端采用Vue CLI框架

标准接口

支持队列

无缝事件机制

数据表格导出

• Excel数据导出,导出表格更加美观可视；

数据统计分析

强大的后台权限管理

强大的表单生成控件

预览图

本项目完全采用前后端分离开发，实际上包含了三个项目，后台前端项目，前台前端项目以及后端接口项目，前台前端使用的是uni-app，特别方便大家二次编译适配多个平台，以及封装APP。 后台界面

前台界面

• 运行环境要求JAVA1.8

注意：请尽量遵循阿里巴巴开发规范，可以减少在开发过程中出现不必要的错误 项目内包含三个子项目

当然我也希望大家都能够为该项目做一下代码贡献，步骤如下：

• fork 代码
• 创建自己的分支
• commit并push修改的密码到你fork的代码仓库
• 提交 pr

总结

本篇文章篇幅限制，一些开发注意事项没能详细的说明，大家可以去开源项目说明里仔细看，还有很详细的帮助文档，开源是为了不让大家在重复造轮子，希望大家从本开源项目能学习到知识，有所收获，无论你是学生还是普通的开发者，让我们在技术的世界日渐精进，为国内开源事业做一份自己的贡献。 这篇文章就先这样了，然后也希望大家动动发财的小手，帮忙点个 Star或者分享出去让更多的人可以看到这个项目，谢谢大家的支持啦。

订单系统：订单生成及其状态机流转介绍

编辑导语：随着线上购物成为了人们的日常甚至是生活习惯，各大电商平台的竞争也逐渐激烈。用户在购物过程中各个环节的体验感，对于留住用户来说尤为重要。本文作者以订单系统为例，对订单生成及其状态机流转进行了介绍。

众多用户逛taobao、TMall除了打发时间外，其最终目的就是买买买，即促成订单交易。

订单从产生到最终的交易完成，整个正向流程需要经历很多的环节。订单系统是电商系统重要的模块之一，订单的促成是整个电商平台的利益根本，电商后台基本上所有的工作都是围绕着订单开展的。

补一句：主流的电商大平台利益来源方向比较多，比如：会员费、广告收入、增值服务、竞价模式等。

本篇主要聊下从订单创建到订单支付完成这部分，介绍下涉及的系统的各个环节，回顾总结下这些简单的内容，供大家娱乐。

订单系统记录了所有的交易信息，与用户、运营、物流、财务等都有着密切的关系，既需要公司内部各部门人员进行相关操作，也需要支持C端用户的下单操作。

本篇主要从用户下单路径、订单下单流程、订单字段说明、订单类型、订单状态(状态机)来介绍从订单创建到订单支付完成的流程，供大家参考，有不恰当的地方望指出。

在订单形成之前，用户首先通过各种方式查询到商品，比如搜索框、分类入口、首页活动页等等，据统计超过一半的销售额来自搜索框途径。然后选择意向商品，进入其详情页，查看商品的视频解说、商品详情，认真研究评论、问答。

对商品满意后 ，直接购买结算，但是也有先加入购物车，再看看其他好物，然后统一在购物车下单结算。购物车内，勾选商品，然后结算；这时候会选择收货地址、是否使用优惠券等虚拟资产、发票类型、支付方式等。

最后检查无误后，提交订单并成功支付，安安静静的等待商家发货。

(下单路径图)

用户在前台通过几个步骤就完成了整个下单的过程，看似简单，实则订单在后台各系统之间，不停的在流程转，下图所示就是订单下单整个流程。

(下单泳道图)

整个下单流程需要和多个系统相互对接，首先用户下单前必须要对他进行风控校验，避免出现等风险。

然后商品信息从商品系统中获取，各种优惠券信息、促销活动数据从促销活动中获取，会员价、会员折扣等会员权益从会员中心获取，库存信息从库存系统获取，最后根据运费模板计算运费，根据订单金额、运费、优惠总金额计算实付金额。

(下单流程图)

订单创建完成后，我们一起来看看订单信息中包含了哪些字段。

1. 用户信息：用户ID、用户账号、用户等级、姓名；
2. 商品信息：店铺信息、商品图片、商品名称、价格、规格、购买数量；
3. 收货信息：收货人、收货地址、联系号码；
4. 时间信息：创建时间、付款时间、发货时间、成交时间；
5. 促销信息：优惠券、促销活动、积分抵扣、金币抵扣等其他虚拟资产；
6. 支付信息：支付方式、支付单号、商品总金额、实付金额、运费、运费险、优惠券优惠金额、促销活动优惠金额、积分抵扣金额、金币抵扣金额；
7. 发票信息：发票类型、抬头类型、发票抬头、税号、发票内容；
8. 订单信息：订单编号、订单来源、交易快照、订单状态；
9. 物流信息：快递单号、快递公司、物流状态、时间节点状态、签收状态、配送员信息；

电商中商品大体可分为实物商品和虚拟商品，虚拟商品中又包括数字商品和非数字商品。实物商品指的是指天猫商城内，正在出售的真实货物，如鞋包服饰、电子产品、零食饮料等。这些实物商品，都是用手摸得着的真实东西。

虚拟商品是无实物性质，网上发布时默认无法选择物流运输的商品。可由虚拟货币或现实货币交易买卖的虚拟商品或者虚拟社会服务等。

虚拟商品是指电子商务市场中的数字产品和服务（专指可以通过下载或在线等形式使用的数字产品和服务），具有无实物性质，是在网上发布时默认无法选择物流运输的商品，可由虚拟货币或现实货币交易买卖的虚拟商品或者虚拟社会服务。

虚拟商品主要包括计算机软件、股票行情和金融信息、新闻、书籍、杂志、音乐影像、电视节目、搜索、虚拟云主机、虚拟云盘、虚拟光驱、APP虚拟应用、虚拟商品、网络游戏中的一些产品和在线服务。

某宝上就有好多有趣的虚拟产品，如教程类视频、算命、孤寡青蛙等等。

当然订单大体也可为分为实物订单和虚拟订单，虚拟订单无需物流发货，所以没有物流状态，在订单流转和结算流程比实物订单相对要简单点。由于虚拟订单的特殊性，通常是没有售后流程的。

订单也有自己的命周期，在订单生成后，其状态会随着订单在不同系统之间流转而更新状态。要注意的是不同的订单类型，他们的的订单状态会有差异。比如虚拟订单就没有待发货、待收货等状态。

接下来我们以实物订单为例，具体介绍订单状态是如何流转变化的。

如果是先付款订单，用户下单后迟迟未支付，那么订单状态变为待付款。一般情况下，待付款的订单可以保留24小时、30分钟等时间，当超过规定时间还没支付，订单就会超时自动取消。

ps：这里会涉及到锁定、释放库存的功能，留到后面的文章再讲。

用户拍下物品成功付款之后，商家还没有发货，订单的商品正等待卖家发货的一个状态。通常用户在商品详情页能看到 “付款后48小时内发货” ，海淘商品可能是“几天到几天内发货”。

订单商品发货成功后，订单状态将更新为待收货状态。也就是用户进入待收货流程，待货物到达之后，会有快递员通知用户收货。

用户主动确认收货或者自动确认收货，自动确认收货的规则按照实物商品、虚拟商品均有不同，如下规则(某宝)：

1）虚拟商品

• 自动充值商品 ，完成支付宝付款后，系统会马上自动确认收货；
• 自动发货商品 ，自“卖家已发货”状态起的24小时后，系统会自动确认收货。
• 虚拟物品 ，自“卖家已发货”状态起的3天后，系统会自动确认收货。

2）实物商品

• 购买时选择的物流方式为快递、EMS、不需要物流，自“卖家已发货”状态起的10天后，系统会自动确认收货。
• 购买时选择的物流方式为平邮，自“卖家已发货”状态起的30天后，系统会自动确认收货。

3）延长收货功能

对于普通实物的收货可以延长3天收货，虚拟交易的收货可以延长1天，每个订单只能延长一次。

付款之前用户由于各种因素主动取消订单或者订单超时未付款，都会导致订单状态由待付款变为已取消。

目前售后类型通常分为：退款、退货退款、换货，用户在付款后发货前申请退款，商家发货后用户申请退换货或退款退货。值得注意的是售后流程也有自己的售后状态机，后续会对售后类型的内容详细介绍，敬请关注。

当订单售后完结时的状态，目前很多平台将”已取消“的订单状态合并到“交易关闭”中。

在订单正向流程中，订单状态机会随着其在不同系统之间流转而更新状态，以下流程仅涉及正向的，不包含用户发起订单取消或发起售后的状态机。

(订单正向状态机流程图-来自糜鹿产品)

以上就是本篇的全部内容，希望对大家有所启发，由于订单系统的设计与业务范围和流程联系比较紧密，接下来会对订单系统相关细节内容做一个详细介绍，感谢阅读。

作者：道三，电商PM；公众号: 产品大秘籍

本文由 @道三 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。

本文作者及来源:Renderbus瑞云渲染农场https://www.renderbus.com