第一章 绪论
1.1 研究背景与意义
1.1.1 研究背景
随着高校招生人数不断增多,校园内闲置物品的数量和种类也变得越来越多,传统的线下摆摊、校园公告栏、校内论坛等方式,存在着信息传播范围小、供需不匹配、交易难以追踪等问题。传统的模式多是靠人工登记、口头约定来完成的,信息滞后、表述不清的情况时有发生,从而导致纠纷的发生,不能保证交易的规范性和安全性。目前,移动互联网以及Web技术的发展给创建线上交易平台给予了完备的技术支持,各种电商系统也渐渐渗入到垂直的生活服务范畴之中[1]。在这种情形下,创建一个以校园为依托、有着明显角色分工和完整交易流程的二手交易平台,已经成了解决传统交易痛点的必然要求,也十分必要且迫切[2]。
1.1.2 研究意义
本课题研究的校园二手交易平台是把用户、商品、订单、物流、售后等模块进行系统的整合,相比起人工管理或者分散的论坛发帖方式,它形成了商品发布-交易撮合-物流跟踪-售后反馈的线上的闭环。有利于提高校园闲置资源的配置效率,减少由于信息不对称造成的资源浪费,用标准的流程设计来提高交易信息的管理水平以及决策支持能力。另外平台所加入的角色权限控制以及在线交流功能可以对买卖双方的行为进行规范,使校园二手交易朝着有序、诚信的方向发展,对校园生活服务质量的提高和绿色节约型校园的建设有着十分重要的现实意义和社会价值。
1.2 国内外研究现状
1.2.1 国内现状
国内对于校园二手交易平台的研究,由原来的传统的Web应用发展到现在的移动端、轻量化的方向。早期的研究大多都是使用基于Java Web或者SSH框架的PC端系统开发,近几年随着移动互联网的发展,研究重心也慢慢转向了跨平台、高便利性。微信小程序因为免安装、易传播的特点成为主流的技术选择,Vue、React等前端框架和Spring Boot后端架构的结合也经常被使用。目前的研究主要从用户体验、地理信息服务和社会属性三个方面融合入手,从全流程交易闭环管理、多角色权限精细化控制、售后沟通机制的整合等方面还有待于进一步的提高。
蒋瑞霞、王莉(2024)在2024年提出使用地理信息服务平台创建校园二手交易市场,使用位置服务提供周边商品推荐[3]。该系统给本系统商品分类和推荐模块提供一种空间维度融合的方法,能够提高用户获取闲置物品信息的准确度。胡佳静在2023年使用React Native框架创建了一个跨平台二手交易应用,主要是解决多端适配的问题[4]。跨平台的设计思想对本系统前后台分离的结构有借鉴意义,有利于用户在不同的终端设备上使用时不觉得慢。2022年陈怡婧等人利用微信云开发技术创建了二手交易小程序,把后端服务和云数据库结合起来,从而降低运维成本[5]。无服务器化的思想可以使得本系统的部署更加简单。赵冰等(2022)根据微信小程序开发二手物品交易平台,主要是从商品展示、发布流程的优化入手[6]。简洁的商品录入界面给本系统闲置物品管理模块提供一定的借鉴意义,有利于卖家的简单操作。赵明等(2022)利用微信小程序创建了高校二手物品交易平台,并着重加强了用户的认证以及信息审核系统[7]。本系统举报反馈、订单售后管理模块的可信交易环境的建立需要依靠本系统的安全设计思想。
综合以上国内的研究发现,目前的研究大多采用移动端、轻后端的技术路线,形成了各种各样的解决方案。现有的成果对于商品发布、基础浏览、交易撮合这些方面比较完善,但是对订单全生命周期的追踪、物流配送状态的可视化以及售后申请的处理等完整的交易闭环没有覆盖。在以上研究的基础上,本文在订单管理、订单配送管理、订单售后管理这三个模块上进行加强,在此基础上加入了在线沟通的功能来弥补国内现有的研究在交易后服务方面的不足。
1.2.2 国外现状
国外对于二手交易平台的研究,大多都是集中在用户行为分析、信任机制的创建和平台的运营策略上。从系统实现的角度来说,使用跨平台开发技术以及轻量级后端框架的校园或者社区级二手交易系统比较多。研究者关注的是怎样借助技术手段来削减交易摩擦,改善信息匹配的速度,再把社区治理理论运用到用户参与意愿的分析当中去。虽然国外文献对算法模型以及行为经济学的分析比较深入,但是具体到校园场景的全功能系统实现案例比较少,在物流跟踪和售后管理功能的整合上也比国内系统要简略。
Yuan J等人的2024年关于微信小程序下校园二手平台设计与实现的研究中,用用户调研来改进功能布局[8]。以用户为中心的设计理念给本系统前台界面交互流程提供了一些思路。2024年刘宇用Vue3+SpringBoot搭建了校园二手教材交易系统,主要实现了商品查询、用户登录等部分[9]。该种前后端分离的架构模式给本系统使用SpringBoot和Vue混合架构提供了一种参考。Wei G等人于2023年从C2C交易动态决策的角度出发,对二手平台买卖双方的博弈行为进行分析,得出定价、信誉机制等会影响交易成功率[10]。从而使本文所建立的系统中关于订单管理以及举报反馈模块信用约束策略更加合理。YuruL等人于2023年研究了社区治理机制对于二手平台交易意向的促进作用,得出结论认为互动沟通可以提高用户的信任[11]。该发现直接证明了本系统在线沟通模块的存在是可行的,有利于提高买卖双方的协商速度。Pedro H等人在2022年对消费者参与在线二手交易的影响因素进行了研究,认为平台便捷性以及售后服务的好坏都是关键的影响因素[12]。该结论可以为本系统的优化订单售后管理以及物流配送环节提供依据,有利于形成更好的交易闭环。
国外关于交易信任机制、用户行为分析的研究比国内要深得多,给本系统理论研究打下了基础。就目前来说,国内的研究更多的是从系统功能的落实角度出发,并且是移动化的。本系统借鉴国外用户互动、信任构建方面的先进思想,依据我国校园情况创建出功能齐全、流程明确的本土化校园二手交易市场。
1.3 主要研究内容
本文主要对校园二手交易平台的完整开发过程进行了研究,主要是对用户认证、商品管理、交易流程跟踪、互动交流、后台维护等主要部分进行了研究。研究内容是系统的需求分析、系统架构设计、系统功能模块划分、数据库创建、前后端编码实现、系统测试验证。平台使用Spring Boot搭建RESTful风格的后端服务,用MyBatis-Plus简化了数据访问层的开发工作,前端分别给普通用户和管理员创建了两个独立的Vue2可视化界面。主要对普通用户、卖家、管理员在商品发布、订单处理、物流配送、售后申请、举报反馈等业务流程中所用的权限进行划分,并且分析各个用户的使用方便程度。
系统具体的研究内容有六个方面。建立用户注册登录和使用Redis Token来实现会话保持的系统,支持普通用户、卖家和管理员身份认证及权限管理。第二部分是设计闲置物品的管理系统,可以对商品发布信息进行管理、多个规格SKU设置、分类检索和上下架的状态更新。第三部分是完成一个完整的交易闭环,即购物车管理、下单、在线支付模拟、订单配送状态追踪和订单售后申请处理。第四,在商品详情页上使买卖双方可以进行即时消息的在线交流,有客服聊天室的功能。第五,在后台管理系统中给管理员赋予商品分类管理、通知公告发布、新闻资讯维护、闲置求购审核以及举报反馈处理等操作权限。第六个就是闲置求购子模块,用户发布求购信息之后,平台就会寻找合适的卖家来满足用户的求购需求。经过上述的研究内容之后,可以得到一个功能齐全、流程清晰、适合于校园环境的二手交易平台。
第二章 相关技术介绍
2.1 Spring Boot框架
Spring Boot是由Pivotal团队开发出来的全新框架,它的主要目的就是简化Spring应用的初始搭建和开发过程。该框架用约定优于配置的基本标准,用自动配置的方法大大减少了项目的配置工作量。Spring Boot内置了Tomcat、Jetty等Servlet容器,应用可以打包为独立的JAR文件直接运行,无需部署WAR包。框架中包含了很多的Starters,开发人员可以直接将数据库访问、Web开发、安全控制等常用功能的依赖添加到项目中。校园二手交易平台后端开发中用到的是Spring Boot这个基本的架构框架来实现各个业务模块之间依赖注入以及生命周期[13]。利用它的自动配置特性,可以很好地把Spring MVC和MyBatis-Plus结合起来,形成稳定的、可靠的Service层。Spring Boot提供的Actuator模块可以对应用的运行状态进行监控,给平台的运维提供方便。
Spring Boot框架用基于Java注解的配置方式代替了传统的XML配置文件,使得代码结构更加清晰。其条件化的配置功能可以按照不同的环境去加载不同的Bean,从而提高系统在各个部署环境下对其适应性。框架内部的日志抽象层可以使用Logback、Log4j2等不同的日志实现来记录校园二手交易平台用户的操作轨迹以及异常信息。Spring Boot为统一的事务管理接口提供了声明式事务注解,利用该接口就可以很方便地对订单处理、支付过程等重要的业务进行数据的一致性控制。该框架嵌入式Servlet容器有热部署的特点,在开发调试阶段可以进行功能上的修改,从而加快闲置物品管理、购物车操作等模块的开发速度。Spring Boot已经构建起了一个比较完善的生态系统,给平台的扩展打下了良好的基础。
2.2 Spring MVC框架
Spring MVC是基于Servlet API构建的原始Web框架,其核心组件包括DispatcherServlet、HandlerMapping、Controller和ViewResolver。DispatcherServlet作为前端控制器接收所有HTTP请求,依据HandlerMapping将请求分发给对应的Controller处理方法。Controller层处理完业务逻辑后返回ModelAndView对象,ViewResolver负责解析视图并渲染响应结果。框架支持多种视图技术,包括JSP、Thymeleaf以及RESTful风格下的JSON响应。在校园二手交易平台中,Spring MVC承担接口层职责,接收前端提交的登录注册请求,将参数封装后传递至服务层完成闲置物品的增删改查操作[14]。
Spring MVC注解驱动的开发方式大大提高了接口的编写速度。@RestController注解标识的控制器类可以直接返回JSON数据,而不需要像传统的JSP页面一样进行渲染。@RequestMapping以及它的子类能够正确对应到请求路径和HTTP方法上,可以实现用户端前台和管理员后台接口分离的设计。框架提供的一种参数绑定功能可以把请求参数自动转换成Java对象,减轻了对于地址信息、订单数据等复杂的表单处理工作。数据校验注解和全局异常处理器一起使用来保证购物车的数量、商品的价格等输入字段是合法的。将Spring MVC拦截器机制同Spring Boot安全配置结合起来,从而达到使用Token进行用户认证的目的,对订单配送、售后申请这些需要保护的接口加以保护。该框架使得控制层的代码比较轻,业务逻辑和视图渲染可以得到较好的解耦。
2.3 MyBatis-Plus持久层框架
MyBatis-Plus是在MyBatis的基础上增强的工具库,在保留MyBatis所有特性的同时又增加了许多方便的功能。框架主要的增强点有通用CRUD操作、条件构造器、分页插件、代码生成器。通用Mapper接口内置了insert、delete、update、select等基础方法,开发者无需编写XML映射文件即可完成单表操作。条件构造器QueryWrapper可以进行链式调用,生成动态查询条件,不会出现繁琐的SQL拼接问题。校园二手交易平台数据访问层使用MyBatis-Plus和MySQL数据库交互来存储用户信息、商品分类、订单记录等实体对象[15]。由于具有逻辑删除的特点,闲置物品的下架状态可以被保留下来,便于数据审计。
MyBatis-Plus的分页插件和前端分页组件配合得非常好,只需要传入当前页和每页大小这两个参数就可以实现分页查询和总数统计。乐观锁插件对于库存管理来说比较适用,在多个用户同时发出购买请求的时候,可以避免出现超卖的情况。ActiveRecord模式可以使得实体类可以直接调用数据访问方法,从而简化代码结构,使二手交易平台中购物车的操作以及收货地址的管理更加直观。MyBatis-Plus自带性能分析插件和SQL执行分析器可以找出慢查询并加以改善,从而提高商品搜索、订单列表等的操作速度。该框架可以对多个数据源进行配置,目前校园二手交易平台没有使用到,但是为以后的扩展留有余地。MyBatis-Plus与Spring Boot的无缝集成,使数据访问层的开发效率得到明显提升。
2.4 MySQL关系型数据库
MySQL是目前使用最广的开源关系型数据库管理系统,具有跨平台支持、存储引擎多种、事务处理可靠等特点。InnoDB存储引擎是MySQL的默认存储引擎,行级锁、外键约束可以保证数据的完整性和并发性。MySQL支持标准的SQL语句,可以和JDBC接口进行连接,可以和Java程序稳定地连接。该数据库可以提供视图、存储过程、触发器等各方面的功能来满足各种业务逻辑的需求。校园二手交易平台的MySQL主要负责所有的业务数据存储,设计了用户表、商品表、订单表、物流表等多张关系表,并用主外键约束来保证数据的一致性[16]。
MySQL的索引优化对于提高查询性能来说十分重要,平台对于商品名称模糊搜索、订单编号精确匹配这些高频的操作创建了B+树索引,使得响应时间大大减少。事务隔离级别设置为READ_COMMITTED,保证了订单支付和库存扣减的原子性,但是又不会出现不可重复读的问题。由于MySQL支持主键自增,所以各个实体的记录ID的产生过程变得简单,不需要单独编写序号生成器。数据库中的慢查询日志可以用来找到执行效率低下的SQL语句,从而对后台统计看板的数据聚合查询进行持续的优化。使用MySQL定时备份的方式,可以保证平台的重要数据有备份,避免出现异常情况下数据丢失的情况。由于MySQL具有稳定的特性以及易于使用的功能,可以满足校园二手交易平台对于数据持久化的所有需求。
第三章 系统分析
3.1 可行性分析
3.1.1 技术可行性
本系统采用B/S架构,前端使用Vue框架创建独立的用户端和管理端界面,后端使用Spring Boot集成Spring MVC和MyBatis-Plus来实现业务逻辑,MySQL数据库用来持久化存储用户和交易数据。上述技术组合在同类信息管理系统中已经得到了广泛的使用,并且是非常成熟稳定的。开发环境使用JDK8和Node.js,用Maven来管理后端的依赖,用npm来管理前端的依赖,整个开发过程可以在单机上完成。从性能上来说,校园二手交易平台的并发用户量很小,常规PC服务器的硬件配置就可以满足日常访问的需求。数据安全上要防止SQL注入和跨站脚本攻击,采用MyBatis-Plus预编译查询以及Vue数据绑定的方式从根本上杜绝这两种情况的发生。网络传输的敏感信息(用户密码)用RSA非对称加密来保证登录过程中的凭证安全。因此,系统的技术上是可行的。
3.1.2 经济可行性
项目投入主要是前期开发阶段的人力成本,硬件设备使用的是现有的个人计算机和实验室服务器,不需要再购买新的硬件。软件开发使用的是Spring Boot、Vue、MySQL等开源技术栈,不需要支付商业软件的授权费用。系统部署在校园内部服务器上,网络带宽和存储资源依靠学校的现有基础设施来提供,运行过程中只产生少量的电力和维护人工成本。投入使用之后的间接经济效益有两点,一是减少学生购买新物品的支出,二是降低校园废弃物的处理费用。投入产出比合理,有经济实施的基础。因此,该系统在经济上是可行的。
3.1.3 操作可行性
目标用户是在校学生和校园管理人员,两者的共同点就是每天都会使用智能手机或者计算机浏览网页。系统采用Web的方式进行部署,用户通过浏览器就可以访问,不需要安装额外的客户端软件,降低了使用门槛。学生用户通过统一登录入口进入到个人中心之后,商品搜索、订单查询、在线沟通等功能入口的布置也契合主流电商平台的习惯,使用起来比较方便。管理人员进入独立后台界面,各个管理模块用表格化展示、表单化编辑的方式呈现出来,数据操作的逻辑也清楚。系统上线之后,只需要提供一些基本的操作指引,就可以使用户掌握基本的操作流程,后续的功能更新和维护工作是由开发人员在服务端来完成的,用户端不会感觉到升级。所以系统在操作上是可行的。
3.2 功能需求分析
UML用例图是用于描述系统功能需求的图形化工具,用例图用表示系统和外部参与者之间交互关系的方式来说明系统的功能。用例图用用例来表示系统可以实现的功能,参与者是和系统交互的各种用户或者外部系统。用例图可以被用来在分析和设计阶段使用,使系统具有完整的、正确的功能,并且能够使开发者与客户之间共享语言。用直观的图示,UML用例图给出了系统功能和角色之间的关系。本文会按照角色模块来对系统进行需求分析。
3.2.1 普通用户需求分析
普通用户在系统中承担前台浏览与后台管理的双重职责。前台操作集中在商品搜索与交易环节,用户查看闲置物品详情,将商品加入购物车后生成待支付订单。订单支付成功进入物流配送状态,用户可实时追踪配送进度,签收后发起售后申请。收货地址模块支持地址增删改查操作,确保订单配送信息准确。在线沟通模块允许用户与卖家直接交流,协商商品细节或价格。后台管理部分涵盖个人闲置物品发布与维护,用户自主上架商品或下架已售物品。闲置求购功能帮助用户发布购买需求,等待卖家主动联系。遇到违规内容时,用户提交举报反馈,系统记录并转交管理员处理。普通用户用例图如图3-1所示。

图3-1普通用户用例图
3.2.2 管理员需求分析
管理员负责平台基础数据维护与业务监控。商品分类管理用于构建多级商品目录,支撑前台商品检索与筛选。闲置物品管理审核用户发布的商品信息,对违规内容进行下架处理。订单管理监控全部交易订单,处理异常订单状态变更。订单配送模块指派物流承运商,登记配送单号并更新配送轨迹。订单售后模块受理用户退款退货申请,审核后执行相应操作。闲置求购管理审核用户发布的需求信息,过滤不合规内容。举报反馈模块处理用户投诉,核实后对违规账户采取限制措施。新闻资讯管理发布校园二手交易相关提示或平台公告,维护通知公告内容。注册用户与用户组管理保证系统角色权限分配正确。管理员用例图如图3-2所示。

图3-2管理员用例图
第四章 系统设计
4.1 系统架构设计
本系统采用B/S架构模式,将用户界面层与应用服务层及数据持久层分离部署。用户界面层分为普通用户前台与管理后台两套独立Vue2工程,负责数据可视化展示与用户交互操作。应用服务层基于Spring Boot框架构建,整合Spring MVC处理HTTP请求路由。数据持久层使用MyBatis-Plus作为对象关系映射工具,通过数据访问对象接口完成数据库表记录增删改查。整个架构遵循分层解耦原则,上层模块仅依赖下层接口。各层之间通过RESTful API进行数据交换,请求响应采用JSON格式封装。这种设计提升了代码复用性与可维护性,降低了单一模块修改对整体系统的影响范围。系统架构图如图4-1所示。
图4-1系统架构图
4.2 系统结构功能设计
系统面向普通用户与管理员两类角色提供服务。普通用户在前台完成闲置物品浏览、购物车管理、订单支付及收货地址维护等操作;进入后台可发布闲置物品,管理个人商品上下架状态,在线与其他用户沟通,管理求购信息并提交举报反馈。管理员进入独立后台界面,负责商品分类目录构建、闲置物品内容审核、新闻资讯与通知公告发布、订单全过程监控、物流配送任务指派及售后申请处理,同时对求购信息与举报反馈进行审核。该系统功能结构如图4-2所示。
图4-2系统功能结构图
4.3 系统流程设计
4.3.1 总体业务流程设计
系统总体业务流程从用户访问系统开始。未认证用户注册账户后登录平台,拥有浏览闲置物品权限。普通用户搜索商品查看详情,将商品加入购物车生成待支付订单。支付成功进入配送环节,用户追踪物流状态确认收货。交易完成后可发起售后申请或评价。该流程覆盖商品发布、订单流转到售后的完整链路,确保交易闭环。总体业务流程如图4-3所示。
图4-3总体业务流程流程图
4.3.2 订单管理流程设计
用户确认购物车商品后跳转订单确认页面,填写收货地址与配送方式。提交订单生成待支付记录,系统扣减对应商品库存。用户完成支付操作,订单状态变更为待发货。卖家收到通知后安排发货,录入物流单号更新状态。用户签收后订单进入完成状态,触发积分或信用更新。订单管理流程如图4-4所示。
图4-4订单管理流程图
4.3.3 闲置物品管理流程设计
普通用户登录后进入个人中心,填写商品标题、描述、价格及分类信息。上传商品图片选择多规格SKU,提交发布申请。系统对内容进行初步合法性校验,符合要求则商品上架展示于前台列表。用户可随时修改商品信息或下架已售物品。管理员对异常商品执行强制下架操作。闲置物品管理流程如图4-5所示。
图4-5闲置物品管理流程图
4.3.4 在线沟通流程设计
买卖双方在商品详情页点击发起对话按钮,系统创建临时会话通道。用户输入消息内容发送,消息实时传递至对方会话窗口。聊天界面显示消息发送时间与未读提示。双方可在一个会话窗口中持续交流商品细节、价格协商与交付安排。该流程支持文本消息传输,保障沟通及时性。在线沟通流程如图4-6所示。
图4-6在线沟通流程图
4.3.5 售后申请流程设计
用户登录后在已完成订单列表中选择需要售后的订单,点击申请售后按钮进入申请页面。填写售后类型(仅退款或退货退款)、说明具体问题并上传凭证图片。提交申请后系统生成售后记录,订单状态变更为售后处理中。卖家收到申请后审核信息,同意则执行退款或退货操作,拒绝则需填写拒绝理由。售后申请流程如图4-7所示。
图4-7售后申请流程图
4.4 数据库设计
在数据库设计时,用ER图来将概念模型转换成具体的数据库结构。本阶段就是确定每一个数据表的字段类型、约束条件以及表与表之间的关系,为物理设计打下基础。之后再对优化数据存储方案展开分析,保证系统高效并且具备可扩展性。
4.4.1 E-R图设计
用户实体主要包括用户ID、用户名、密码、昵称、邮箱、手机号、头像、用户组、账户状态、上次登录时间、创建时间。实体属性图如图4-8所示。
图4-8用户实体属性图
普通用户实体主要包括普通用户ID、用户ID、用户姓名、用户性别、用户手机、创建用户ID、创建时间、更新时间。实体属性图如图4-9所示。
图4-9普通用户实体属性图
闲置物品实体主要包括闲置物品ID、普通用户、标题、封面图、描述、原价、卖价、库存、商品分类、正文、主图1、主图2、主图3、主图4、主图5、店铺名称、物品成色、店铺公告、规格、上架状态、创建用户ID、创建时间、更新时间。实体属性图如图4-10所示。
图4-10闲置物品实体属性图
闲置求购实体主要包括闲置求购ID、普通用户、用户姓名、求购物品、物品图片、求购时间、物品描述、点击数、点赞数、收藏数、评论数、创建用户ID、创建时间、更新时间。实体属性图如图4-11所示。
图4-11闲置求购实体属性图
订单实体主要包括订单ID、订单号、商品ID、商品标题、商品图片、价格、原价、数量、总价、规格、商品分类、联系人姓名、联系人手机、联系人地址、买家ID、商家ID、订单状态、订单备注、配送方式、取货编号、创建时间、更新时间。实体属性图如图4-12所示。
图4-12订单实体属性图
购物车实体主要包括购物车ID、用户ID、商品ID、标题、图片、单价、原价、数量、总价、规格、商品分类、描述、创建时间、更新时间。实体属性图如图4-13所示。
图4-13购物车实体属性图
收货地址实体主要包括收货地址ID、用户ID、姓名、手机、地址、邮编、默认判断、创建时间、更新时间。实体属性图如图4-14所示。
图4-14收货地址实体属性图
物流配送实体主要包括物流配送ID、订单号、商品名称、购买数量、交易总额、发货日期、配送单号、普通用户、收货地址、配送状态、签收状态、联系人名字、商家ID、配送方式、配送员ID、配送员名字、配送详情、创建时间、更新时间。实体属性图如图4-15所示。
图4-15物流配送实体属性图
订单售后实体主要包括订单售后ID、订单ID、订单号、商品ID、商品标题、价格、原价、数量、总价、买家ID、商家ID、订单状态、售后状态、售后回复、售后类型、售后内容、售后凭证、创建时间、更新时间。实体属性图如图4-16所示。
图4-16订单售后实体属性图
举报反馈实体主要包括举报反馈ID、普通用户、用户姓名、反馈时间、反馈类型、反馈内容、审核状态、审核回复、创建用户ID、创建时间、更新时间。实体属性图如图4-17所示。
图4-17举报反馈实体属性图
商品类型实体主要包括商品分类ID、上级分类ID、商品名称、描述、图标、创建时间、更新时间。实体属性图如图4-18所示。
图4-18商品类型实体属性图
图4-19系统E-R图
4.4.2 数据库表设计
用户表主要用来存储平台所有注册账户的登录凭证与基本信息,包括用户名、密码加密密文、昵称、联系方式及账户状态。如表4-1所示。
表4-1用户表
| 1 | user_id | int | 11 | 是 | 是 | 用户ID |
| 2 | username | varchar | 16 | 是 | 否 | 用户名 |
| 3 | password | varchar | 64 | 是 | 否 | 密码 |
| 4 | nickname | varchar | 16 | 否 | 否 | 昵称 |
| 5 | varchar | 64 | 否 | 否 | 邮箱 | |
| 6 | phone | varchar | 11 | 否 | 否 | 手机号码 |
| 7 | avatar | varchar | 255 | 否 | 否 | 头像地址 |
| 8 | user_group | varchar | 32 | 否 | 否 | 所在用户组 |
| 9 | state | smallint | 6 | 是 | 否 | 账户状态 |
| 10 | login_time | timestamp | – | 否 | 否 | 上次登录时间 |
| 11 | create_time | timestamp | – | 是 | 否 | 创建时间 |
普通用户表主要用来记录用户附加信息如真实姓名、性别及联系方式,补充基础账户表中未涵盖的身份数据。如表4-2所示。
表4-2普通用户表
| 1 | regular_user_id | int | 11 | 是 | 是 | 普通用户ID |
| 2 | user_id | int | 11 | 是 | 否 | 用户ID |
| 3 | user_name | varchar | 64 | 否 | 否 | 用户姓名 |
| 4 | user_gender | varchar | 64 | 否 | 否 | 用户性别 |
| 5 | users_mobile_phone | varchar | 64 | 否 | 否 | 用户手机 |
| 6 | create_by | int | 11 | 是 | 否 | 创建用户ID |
| 7 | create_time | datetime | – | 是 | 否 | 创建时间 |
| 8 | update_time | timestamp | – | 是 | 否 | 更新时间 |
闲置物品表主要用来存储用户发布的二手商品完整信息,涵盖标题描述、价格库存、商品分类、多张展示图片及上下架状态。如表4-3所示。
表4-3闲置物品表
| 1 | user_idle_items_id | int | 11 | 是 | 是 | 闲置物品ID |
| 2 | regular_user | int | 11 | 否 | 否 | 普通用户 |
| 3 | cart_title | varchar | 125 | 否 | 否 | 标题 |
| 4 | cart_img | text | 65535 | 否 | 否 | 封面图 |
| 5 | cart_description | varchar | 255 | 否 | 否 | 描述 |
| 6 | cart_price_ago | double | – | 是 | 否 | 原价 |
| 7 | cart_price | double | – | 是 | 否 | 卖价 |
| 8 | cart_inventory | int | 11 | 是 | 否 | 商品库存 |
| 9 | cart_type | varchar | 64 | 是 | 否 | 商品分类 |
| 10 | cart_content | longtext | 4294967295 | 否 | 否 | 正文 |
| 11 | cart_img_1 | text | 65535 | 否 | 否 | 主图1 |
| 12 | cart_img_2 | text | 65535 | 否 | 否 | 主图2 |
| 13 | cart_img_3 | text | 65535 | 否 | 否 | 主图3 |
| 14 | cart_img_4 | text | 65535 | 否 | 否 | 主图4 |
| 15 | cart_img_5 | text | 65535 | 否 | 否 | 主图5 |
| 16 | store_name | varchar | 64 | 否 | 否 | 店铺名称 |
| 17 | item_color | varchar | 64 | 否 | 否 | 物品成色 |
| 18 | store_announcement | text | 65535 | 否 | 否 | 店铺公告 |
| 19 | sku | longtext | 4294967295 | 否 | 否 | 规格 |
| 20 | list_status | smallint | 6 | 否 | 否 | 上架状态 |
| 21 | create_by | int | 11 | 是 | 否 | 创建用户ID |
| 22 | create_time | datetime | – | 是 | 否 | 创建时间 |
| 23 | update_time | timestamp | – | 是 | 否 | 更新时间 |
闲置求购表主要用来存储用户发布的购买需求信息,包括求购物品名称、期望成色、预算范围及联系方式等核心字段。如表4-4所示。
表4-4闲置求购表
| 1 | user_idle_to_buy_id | int | 11 | 是 | 是 | 闲置求购ID |
| 2 | regular_user | int | 11 | 否 | 否 | 普通用户 |
| 3 | user_name | varchar | 64 | 否 | 否 | 用户姓名 |
| 4 | buy_items | varchar | 64 | 否 | 否 | 求购物品 |
| 5 | item_pictures | varchar | 255 | 否 | 否 | 物品图片 |
| 6 | buying_time | date | – | 否 | 否 | 求购时间 |
| 7 | item_description | longtext | 4294967295 | 否 | 否 | 物品描述 |
| 8 | hits | int | 11 | 是 | 否 | 点击数 |
| 9 | praise_len | int | 11 | 是 | 否 | 点赞数 |
| 10 | collect_len | int | 11 | 是 | 否 | 收藏数 |
| 11 | comment_len | int | 11 | 是 | 否 | 评论数 |
| 12 | create_by | int | 11 | 是 | 否 | 创建用户ID |
| 13 | create_time | datetime | – | 是 | 否 | 创建时间 |
| 14 | update_time | timestamp | – | 是 | 否 | 更新时间 |
订单表主要用来记录交易双方确认的购物信息,包含商品快照、价格数量、收货地址及当前流转状态。如表4-5所示。
表4-5订单表
| 1 | order_id | int | 11 | 是 | 是 | 订单ID |
| 2 | order_number | varchar | 64 | 否 | 否 | 订单号 |
| 3 | goods_id | mediumint | 9 | 是 | 否 | 商品ID |
| 4 | title | varchar | 255 | 否 | 否 | 商品标题 |
| 5 | img | varchar | 255 | 否 | 否 | 商品图片 |
| 6 | price | double | – | 是 | 否 | 价格 |
| 7 | price_ago | double | – | 是 | 否 | 原价 |
| 8 | num | int | 11 | 是 | 否 | 数量 |
| 9 | price_count | double | – | 是 | 否 | 总价 |
| 10 | norms | varchar | 255 | 否 | 否 | 规格 |
| 11 | type | varchar | 64 | 是 | 否 | 商品分类 |
| 12 | contact_name | varchar | 32 | 否 | 否 | 联系人姓名 |
| 13 | contact_phone | varchar | 11 | 否 | 否 | 联系人手机 |
| 14 | contact_address | varchar | 255 | 否 | 否 | 联系人地址 |
| 15 | user_id | int | 11 | 是 | 否 | 买家ID |
| 16 | merchant_id | mediumint | 9 | 是 | 否 | 商家ID |
| 17 | state | varchar | 16 | 是 | 否 | 订单状态 |
| 18 | remark | text | 65535 | 否 | 否 | 订单备注 |
| 19 | delivery_type | varchar | 16 | 否 | 否 | 配送方式 |
| 20 | pickup_code | varchar | 32 | 否 | 否 | 取货编号 |
| 21 | create_time | timestamp | – | 是 | 否 | 创建时间 |
| 22 | update_time | timestamp | – | 是 | 否 | 更新时间 |
购物车表主要用来暂存用户挑选但未结算的商品,记录商品规格、购买数量及当前价格快照。如表4-6所示。
表4-6购物车表
| 1 | cart_id | int | 11 | 是 | 是 | 购物车ID |
| 2 | user_id | int | 11 | 是 | 否 | 用户ID |
| 3 | goods_id | mediumint | 9 | 是 | 是 | 商品id |
| 4 | title | varchar | 64 | 是 | 否 | 标题 |
| 5 | img | varchar | 255 | 是 | 否 | 图片 |
| 6 | price | double | – | 是 | 否 | 单价 |
| 7 | price_ago | double | – | 是 | 否 | 原价 |
| 8 | num | int | 11 | 是 | 否 | 数量 |
| 9 | price_count | double | – | 是 | 否 | 总价 |
| 10 | norms | varchar | 64 | 否 | 否 | 规格 |
| 11 | type | varchar | 64 | 是 | 否 | 商品分类 |
| 12 | description | varchar | 255 | 否 | 否 | 描述 |
| 13 | create_time | timestamp | – | 是 | 否 | 创建时间 |
| 14 | update_time | timestamp | – | 是 | 否 | 更新时间 |
收货地址表主要用来记录用户维护的多个配送目的地信息,包含收件人姓名、联系电话及详细街道地址。如表4-7所示。
表4-7收货地址表
| 1 | address_id | int | 11 | 是 | 是 | 收货地址 |
| 2 | user_id | mediumint | 9 | 是 | 否 | 用户ID |
| 3 | name | varchar | 32 | 否 | 否 | 姓名 |
| 4 | phone | varchar | 13 | 否 | 否 | 手机 |
| 5 | address | varchar | 255 | 是 | 否 | 地址 |
| 6 | postcode | varchar | 8 | 否 | 否 | 邮编 |
| 7 | default | tinyint | 4 | 是 | 否 | 默认判断 |
| 8 | create_time | timestamp | – | 是 | 否 | 创建时间 |
| 9 | update_time | timestamp | – | 是 | 否 | 更新时间 |
物流配送表主要用来跟踪订单出库后的运输环节,记录配送单号、承运商信息以及签收确认状态。如表4-8所示。
表4-8物流配送表
| 1 | logistics_delivery_id | int | 11 | 是 | 是 | 物流配送ID |
| 2 | order_number | varchar | 64 | 否 | 否 | 订单号 |
| 3 | product_name | varchar | 64 | 否 | 否 | 商品名称 |
| 4 | purchase_quantity | varchar | 64 | 否 | 否 | 购买数量 |
| 5 | total_transaction_amount | double | – | 否 | 否 | 交易总额 |
| 6 | the_date_of_issuance | date | – | 否 | 否 | 发货日期 |
| 7 | delivery_number | varchar | 30 | 否 | 否 | 配送单号 |
| 8 | ordinary_users | int | 11 | 否 | 否 | 普通用户 |
| 9 | shipping_address | varchar | 64 | 否 | 否 | 收货地址 |
| 10 | delivery_status | varchar | 64 | 否 | 否 | 配送状态 |
| 11 | signing_status | varchar | 64 | 否 | 否 | 签收状态 |
| 12 | contact_name | varchar | 255 | 否 | 否 | 联系人名字 |
| 13 | merchant_id | int | 11 | 否 | 否 | 商家id |
| 14 | courier_type | int | 11 | 是 | 否 | 配送方式 |
| 15 | courier_id | int | 11 | 否 | 否 | 配送员ID |
| 16 | courier_name | varchar | 255 | 否 | 否 | 配送员名字 |
| 17 | courier_detail | longtext | 4294967295 | 否 | 否 | 配送详情 |
| 18 | create_time | datetime | – | 是 | 否 | 创建时间 |
| 19 | update_time | timestamp | – | 是 | 否 | 更新时间 |
订单售后表主要用来处理交易完成后的退换货请求,存储售后类型、申请原因、用户凭证及审核处理结果。如表4-9所示。
表4-9订单售后表
| 1 | order_after_sale_id | int | 11 | 是 | 是 | 订单售后ID |
| 2 | order_id | int | 11 | 是 | 否 | 订单ID |
| 3 | order_number | varchar | 64 | 否 | 否 | 订单号 |
| 4 | goods_id | mediumint | 9 | 是 | 否 | 商品id |
| 5 | title | varchar | 255 | 否 | 否 | 商品标题 |
| 6 | price | double | – | 是 | 否 | 价格 |
| 7 | price_ago | double | – | 是 | 否 | 原价 |
| 8 | num | int | 11 | 是 | 否 | 数量 |
| 9 | price_count | double | – | 是 | 否 | 总价 |
| 10 | user_id | int | 11 | 是 | 否 | 买家ID |
| 11 | merchant_id | mediumint | 9 | 是 | 否 | 商家ID |
| 12 | state | varchar | 16 | 是 | 否 | 订单状态 |
| 13 | after_state | varchar | 16 | 是 | 否 | 售后状态 |
| 14 | after_state_reply | varchar | 255 | 是 | 否 | 售后回复 |
| 15 | type | varchar | 255 | 是 | 否 | 售后类型 |
| 16 | content_desc | varchar | 255 | 是 | 否 | 售后内容 |
| 17 | imgs | varchar | 1000 | 否 | 否 | 售后凭证 |
| 18 | create_time | timestamp | – | 是 | 否 | 创建时间 |
| 19 | update_time | timestamp | – | 是 | 否 | 更新时间 |
举报反馈表主要用来存储用户投诉信息,记录举报对象、违规类型、详细描述及管理员审核处理结论。如表4-10所示。
表4-10举报反馈表
| 1 | report_feedback_id | int | 11 | 是 | 是 | 举报反馈ID |
| 2 | regular_user | int | 11 | 否 | 否 | 普通用户 |
| 3 | user_name | varchar | 64 | 否 | 否 | 用户姓名 |
| 4 | feedback_time | datetime | – | 否 | 否 | 反馈时间 |
| 5 | feedback_type | varchar | 64 | 否 | 否 | 反馈类型 |
| 6 | feedback_content | text | 65535 | 否 | 否 | 反馈内容 |
| 7 | examine_state | varchar | 16 | 是 | 否 | 审核状态 |
| 8 | examine_reply | varchar | 255 | 否 | 否 | 审核回复 |
| 9 | create_by | int | 11 | 是 | 否 | 创建用户ID |
| 10 | create_time | datetime | – | 是 | 否 | 创建时间 |
| 11 | update_time | timestamp | – | 是 | 否 | 更新时间 |
商品类型表主要用来构建多级商品目录,存储分类层级关系、类型名称及显示图标路径,支撑前台检索筛选。如表4-11所示。
表4-11商品类型表
| 1 | type_id | int | 11 | 是 | 是 | 商品分类ID |
| 2 | father_id | smallint | 6 | 是 | 否 | 上级分类ID |
| 3 | name | varchar | 255 | 否 | 否 | 商品名称 |
| 4 | desc | varchar | 255 | 否 | 否 | 描述 |
| 5 | icon | varchar | 255 | 否 | 否 | 图标 |
| 6 | create_time | timestamp | – | 是 | 否 | 创建时间 |
| 7 | update_time | timestamp | – | 是 | 否 | 更新时间 |
第五章 系统实现
5.1 普通用户后台功能实现
5.1.1 注册登录功能实现
用户通过前端表单提交注册信息,后端UserController的signUp方法接收数据并调用BaseService的insert方法写入数据库。登录时先对密码进行RSA解密,验证用户组状态及审核状态后生成UUID作为token存入Redis并返回前端。注册登录界面如图5-1所示。
图5-1注册登录界面
核心代码实现如下:
public Map<String, Object>signUp(@RequestBody User user) {
Map<String, String> query = new HashMap<>();
query.put(“username”,user.getUsername());
Listlist=service.selectBaseList(service.select(query, new HashMap<>()));
if (list.size()>0){
return error(30000, “用户已存在”);
}
service.insert(map);
returnsuccess(1);
}
public Map<String, Object>login(@RequestBody Map<String, String> data) {
password =RsaUtils.decryptByPrivateKey(password);
AccessTokenaccessToken= newAccessToken();
accessToken.setToken(UUID.randomUUID().toString().replaceAll(“-”, “”));
redisTemplate.opsForValue().set(accessToken.getToken(),accessToken, duration);
return success(ret);
}
5.1.2 闲置物品管理功能实现
普通用户通过UserIdleItemsController的add方法发布闲置物品,前端提交商品标题、图片、价格、库存、分类等字段。后端将表单数据转换为UserIdleItems实体并调用insert方法持久化,同时通过submit_goods方法同步写入goods表。闲置物品管理界面如图5-2所示。
图5-2闲置物品管理界面
核心代码实现如下:
@PostMapping(“/add”)
@Transactional
public Map<String, Object>add(HttpServletRequestrequest) throwsIOException{
Map<String,Object>paramMap=service.readBody(request.getReader());
UserIdleItemsuser_idle_items= newUserIdleItems();
user_idle_items.setCart_title(paramMap.get(“cart_title”)==null?null:String.valueOf(paramMap.get(“cart_title”)));
user_idle_items.setCart_price(paramMap.get(“cart_price”)==null?null:Double.valueOf(String.valueOf(paramMap.get(“cart_price”))));
this.addEntity(user_idle_items);
returnsuccess(1);
}
5.1.3 在线沟通功能实现
用户通过CustomerChatGroupController创建聊天群组,member字段存储双方用户信息。发送消息时调用CustomerChatLogController的add方法,将消息内容存入content字段。对方登录后通过get_list查询未读消息,阅读后更新read_state和unread_count。在线沟通界面如图5-3所示。
图5-3在线沟通界面
核心代码实现如下:
@PostMapping(“/add”)
@Transactional
public Map<String, Object>add(HttpServletRequestrequest) throwsIOException{
Map<String,Object>paramMap=service.readBody(request.getReader());
CustomerChatGroupcustomer_chat_group= newCustomerChatGroup();
customer_chat_group.setMember(paramMap.get(“member”)==null?null:String.valueOf(paramMap.get(“member”)));
customer_chat_group.setUnread_count(paramMap.get(“unread_count”)==null?null:String.valueOf(paramMap.get(“unread_count”)));
this.addEntity(customer_chat_group);
returnsuccess(1);
}
5.1.4 商品分类管理功能实现
商品分类采用树形结构存储,通过father_id字段关联父子关系。GoodsTypeController提供add和set方法维护分类数据,前端使用级联选择器展示多级分类。用户选择分类后通过handleCategoryChange方法将分类名称存入查询条件。商品分类管理界面如图5-4所示。
图5-4商品分类管理界面
核心代码实现如下:
@PostMapping(“/add”)
@Transactional
public Map<String, Object>add(HttpServletRequestrequest) throwsIOException{
Map<String, Object>addMap=service.readBody(request.getReader());
checkParameter(addMap, “name”, “名称不能为空”);
this.service.insert(addMap);
returnsuccess(1);
}
handleCategoryChange(value) {
if (value &&value.length> 0) {
this.query.cart_type=value[value.length– 1];
}
}
5.1.5 订单管理功能实现
用户下单后OrderController的add方法生成订单记录,状态默认为“待付款”。用户支付后调用update方法将状态改为“待发货”。商家可查询自己的订单列表,通过getBusinessOrderList方法关联goods表过滤商家ID。订单管理界面如图5-5所示。
图5-5订单管理界面
核心代码实现如下:
@RequestMapping(“/get_business_order_list”)
public Map<String, Object>getBusinessOrderList(HttpServletRequestrequest) {
Stringsql= “SELECT t1.*FROMordert1 LEFT JOIN goods t2 ON t1.goods_id = t2.goods_id WHERE t2.user_id =“ +query.get(“user_id”);
if(!StringUtils.isEmpty(query.get(“state”))){
sql=sql+ ”and t1.state=‘“ +query.get(“state”) + “’”;
}
map.put(“list”,service.selectBaseList(sql));
return success(map);
}
5.1.6 订单配送管理功能实现
商家在订单配送表中选择配送方式,LogisticsDeliveryController的add方法创建配送记录。配送员登录后查看配送任务,通过deliveryStatusChange方法将状态更新为“已完成”。用户确认收货后signing_status变为“已签收”。订单配送管理界面如图5-6所示。
图5-6订单配送管理界面
核心代码实现如下:
deliveryStatusChange(data) {
this.post(“~/api/logistics_delivery/set?logistics_delivery_id=” +data.logistics_delivery_id,{delivery_status: “已完成”,signing_status: “待签收” }, (json) =>{this.post(“~/api/order/set?order_number=” +data.order_number,
{delivery_state: “已完成”, state: “待签收” });
});
}
5.1.7 订单售后管理功能实现
用户在订单详情页提交售后申请,OrderAfterSaleController的add方法写入售后记录,after_state默认为“未审核”。管理员通过updateExamineState方法审核,将结果写入after_state和after_state_reply字段。订单售后管理界面如图5-7所示。
图5-7订单售后管理界面
核心代码实现如下:
@GetMapping(“/update_examine_state”)
public StringupdateExamineState(Long id, StringnewState) {
Map<String,String>queryMap= new HashMap<>();
queryMap.put(“id”,String.valueOf(id));
ReportFeedbackreport_feedback=service.findOne(queryMap);
report_feedback.setExamine_state(newState);
this.setEntity(queryMap,newHashMap<>(),report_feedback);
return “审核成功”;
}
5.1.8 闲置求购管理功能实现
用户通过UserIdleToBuyController的add方法发布求购信息,包含求购物品名称、图片、描述和求购时间等字段。系统支持按buy_items字段模糊查询,其他用户可浏览求购列表并联系发布者。闲置求购管理界面如图5-8所示。
图5-8闲置求购管理界面
核心代码实现如下:
@PostMapping(“/add”)
@Transactional
public Map<String, Object>add(HttpServletRequestrequest) throwsIOException{
Map<String,Object>paramMap=service.readBody(request.getReader());
UserIdleToBuyuser_idle_to_buy= newUserIdleToBuy();
user_idle_to_buy.setBuy_items(paramMap.get(“buy_items”)==null?null:String.valueOf(paramMap.get(“buy_items”)));
user_idle_to_buy.setItem_description(paramMap.get(“item_description”)==null?null:String.valueOf(paramMap.get(“item_description”)));
this.addEntity(user_idle_to_buy);
returnsuccess(1);
}
5.1.9 举报反馈功能实现
用户填写举报内容后通过ReportFeedbackController的add方法提交,examine_state默认为“未审核”。管理员登录后台查看举报列表,通过updateExamineState方法进行审核并填写回复内容。举报反馈界面如图5-9所示。
图5-9举报反馈界面
核心代码实现如下:
@PostMapping(“/add”)
@Transactional
public Map<String, Object>add(HttpServletRequestrequest) throwsIOException{
Map<String,Object>paramMap=service.readBody(request.getReader());
ReportFeedbackreport_feedback= newReportFeedback();
report_feedback.setFeedback_content(paramMap.get(“feedback_content”)==null?null:String.valueOf(paramMap.get(“feedback_content”)));
report_feedback.setExamine_state(“未审核”);
this.addEntity(report_feedback);
returnsuccess(1);
}
5.2 普通用户前台功能实现
5.2.1 闲置物品查看功能实现
前台首页通过GoodsController的get_list接口查询上架商品,前端组件list_goods和goods_slisd分别以网格和轮播形式展示。用户点击商品进入详情页,前端调用get_obj接口获取完整信息并通过div_goods组件渲染。闲置物品查看界面如图5-10所示。
图5-10闲置物品查看界面
核心代码实现如下:
get_list_after(json) {
varlist_goods=json.result.list.filter((item) => {
returnitem.list_status=== 1;
}).slice(0, 12);
this.list_goods=list_goods;
}
goodsClickFn(url, o) {
this.{o.goods_id}`,
{ hits:parseInt(o.hits) +1 }, (res) => {
this.$router.push(url);
});
}
5.2.2 收货地址管理功能实现
用户通过AddressController的add和set方法管理收货地址,支持设置默认地址。前端list_address组件展示地址列表,用户可选择地址作为订单收货信息。地址编辑时使用form_address组件进行表单验证和保存。收货地址管理界面如图5-11所示。
图5-11收货地址管理界面
核心代码实现如下:
@PostMapping(“/add”)
@Transactional
public Map<String, Object>add(HttpServletRequestrequest) throwsIOException{
Map<String, Object>addMap=service.readBody(request.getReader());
checkParameter(addMap, “phone”, “手机号不能为空”);
checkParameter(addMap, “address”, “地址不能为空”);
this.service.insert(addMap);
returnsuccess(1);
}
save_address() {
this.{address_id}`,
{ address, name, phone,user_id}, (res) => {
this.$router.push(“./address”);
});
}
5.2.3 在线沟通功能实现
前台用户通过Chat组件发起沟通,系统调用getChatGroup获取聊天群组列表。发送消息时调用sendChat方法,将消息内容写入customer_chat_log表,并更新对方unread_count。接收方打开聊天窗口时自动标记已读。在线沟通界面如图5-12所示。
图5-12在线沟通界面
核心代码实现如下:
asyncsendChat() {
constnewMsg={sender_id:this.UserInfo.user_id, msg:this.sendValue,creat_time: new Date().getTime() };
content.push(newMsg);
await this.{this.currentChat},{ content:JSON.stringify(content) }); awaitthis.$post(~/api/customer_chat_group/set?customer_chat_group_id=${this.currentChat}`,
{unread_count:newUnreadCount});
}
5.2.4 支付订单功能实现
用户在支付页面选择支付方式后调用pay方法,后端将订单状态从“待付款”改为“待发货”。同时更新商品表和闲置物品表的库存数量,并生成取货编号。支付成功后发送消息通知商家发货。支付订单界面如图5-13所示。
图5-13支付订单界面
核心代码实现如下:
pay(type = ‘’) {
this.post(“~/api/order/set?order_number=” +this.query.order_number,{ state: “待发货”,delivery_type:this.query.delivery_type,pickup_code:Math.floor(Math.random() * 1000).toString().padStart(3, ‘0’) }, (res) =>{this.toast(“支付成功”, ‘success’);
this.$router.push(“/order/list”);
});
}
5.2.5 我的订单管理功能实现
用户通过list_order组件查看订单列表,可按订单状态筛选。订单详情页展示商品信息、配送状态和售后入口。用户可取消“待付款”订单,取消时填写原因存入desc字段。已签收订单可申请售后。我的订单管理界面如图5-14所示。
图5-14我的订单管理界面
核心代码实现如下:
cancelOrder(order_number, index) {
this.$post(“~/api/order/set?order_number=” +this.currentCancelData.order_number,
{ state: “已取消”, desc:currDesc.desc}, (res) => {
this.list[this.currentCancelData.index].state = “已取消”;
});
}
get_list_after(json) {
this.list_diff=json.result.list.reduce((acc, o) => {
const existing =acc.find(item =>item.order_number===o.order_number);
existing ?existing.list.push(o) :acc.push({order_number:o.order_number, list: [o],sum_price:o.price_count, state:o.state});
return acc;
}, []);
}
5.2.6 我的购物车管理功能实现
购物车组件list_cart支持商品数量增减和删除操作。用户选择商品后点击结算,系统调用settle_all方法批量生成订单并清空已购商品。商品库存不足时提示并阻止下单。我的购物车管理界面如图5-15所示。
图5-15我的购物车管理界面
核心代码实现如下:
add_num(obj) {
this.{cart_id}`,{ num: num + 1, price_count: price_count +price }, (res) => {
this.list.map(o =>{ if(o.cart_id===cart_id){o.num+= 1;o.price_count+= price; }});
});
}
asyncsettle_all() {
for (leti= 0;i<this.list.length;i++) {
if (this.list[i].selected){ awaitthis.settle_one(this.list[i],i,order_number, address); }
}
}
5.2.7 售后申请功能实现
用户在订单详情页点击售后申请,通过afterSaleOrder方法弹出对话框填写售后类型、内容和凭证图片。提交时调用OrderAfterSaleController的add方法,订单状态变为“售后/退款”,同时发送消息通知管理员。售后申请界面如图5-16所示。
图5-16售后申请界面
核心代码实现如下:
afterSaleOrder(item,idx) {
this.order_number=item.order_number;
this.afterSaleDialogVisible= true;
}
submitAftersale() {
this.post(‘~/api/order_after_sale/add?’,queryDatas, (res) =>{this.post(“~/api/order/set?order_number=” +this.order_number,{ state: “售后/退款” });
this.list[this.afterSaleIdx].state = “售后/退款”;
});
}
5.2.8 闲置求购管理功能实现
用户通过UserIdleToBuyController的add方法发布求购信息,前台list_user_idle_to_buy组件以卡片轮播形式展示。用户可查看详情并联系发布者,系统记录点击数、点赞数和收藏数。闲置求购管理界面如图5-17所示。
图5-17闲置求购管理界面
核心代码实现如下:
@PostMapping(“/add”)
@Transactional
public Map<String, Object>add(HttpServletRequestrequest) throwsIOException{
Map<String,Object>paramMap=service.readBody(request.getReader());
UserIdleToBuyuser_idle_to_buy= newUserIdleToBuy();
user_idle_to_buy.setBuy_items(paramMap.get(“buy_items”)==null?null:String.valueOf(paramMap.get(“buy_items”)));
user_idle_to_buy.setBuying_time(paramMap.get(“buying_time”)==null?null:parseToTimestamp(String.valueOf(paramMap.get(“buying_time”))));
this.addEntity(user_idle_to_buy);
returnsuccess(1);
}
5.2.9 订单配送管理功能实现
用户下单并支付后,配送信息写入logistics_delivery表。用户通过table_logistics_delivery组件查看配送状态,配送中时可查看配送员信息和配送详情。确认收货后signing_status更新为“已签收”。订单配送管理界面如图5-18所示。
图5-18订单配送管理界面
核心代码实现如下:
changeSigning(data, status, index) {
this.post(url, {signing_status: status == “待签收” ? ‘已签收’ : “待签收” }, (json) => {this.post(“~/api/order/set?order_number=” +data.order_number, { state: ‘已完成’ });
this.$toast(“签收成功!”, “success”);
});
}
5.3 管理员功能实现
5.3.1 商品分类管理功能实现
管理员通过GoodsTypeController的add和set方法维护商品分类树,支持添加、修改和删除分类。删除前系统检查该分类下是否有商品关联,有则阻止删除。前端使用el-cascader组件展示多级分类。商品分类管理界面如图5-19所示。
图5-19商品分类管理界面
核心代码实现如下:
asyncdelInfo() {
for (leti= 0;i<list.length;i++) {
let res = awaitthis.get(“~/api/goods/get_list?”,{ type:type.name }); if (res.result&&res.result.list.length> 0){this.message.error(类型“${type.name}”下有关联的内容,无法删除!);
return;
}
}
awaitthis.delAll(list);
}
5.3.2 闲置求购管理功能实现
管理员在后台查看所有用户发布的求购信息,支持按buy_items字段搜索。可删除违规求购信息,同时前端list_user_idle_to_buy组件实时更新列表。闲置求购管理界面如图5-20所示。
图5-20闲置求购管理界面
核心代码实现如下:
get_list_before(param) {
varuser_group=this.user.user_group;
if (user_group!= “管理员”) {
letsqlwhere= “(regular_user= ”+this.user.user_id+ ”or ”;
param[“sqlwhere”] =sqlwhere.substr(0,sqlwhere.length– 4) + “)”;
}
return param;
}
5.3.3 通知公告管理功能实现
管理员通过NoticeController的add方法发布公告,标题和正文存入notice表。前台首页通过swiper_notice组件轮播展示最新公告,列表页支持分页查询。删除公告时前端确认后调用del方法。通知公告管理界面如图5-21所示。
图5-21通知公告管理界面
核心代码实现如下:
@PostMapping(“/add”)
@Transactional
public Map<String, Object>add(HttpServletRequestrequest) throwsIOException{
Map<String, Object>addMap=service.readBody(request.getReader());
checkParameter(addMap, “title”, “标题不能为空”);
this.service.insert(addMap);
returnsuccess(1);
}
5.3.4 新闻资讯管理功能实现
管理员通过ArticleController管理新闻资讯,支持标题、分类和标签筛选。文章正文使用富文本编辑器存储HTML内容。前台首页通过list_article组件展示文章列表,详情页记录点击量。新闻资讯管理界面如图5-22所示。
图5-22新闻资讯管理界面
核心代码实现如下:
@PostMapping(“/add”)
@Transactional
public Map<String, Object>add(HttpServletRequestrequest) throwsIOException{
Map<String, Object>addMap=service.readBody(request.getReader());
checkParameter(addMap, “type”, “分类不能为空”);
checkParameter(addMap, “title”, “标题不能为空”);
this.service.insert(addMap);
returnsuccess(1);
}
add_hits(obj) {
this.$post(‘~/api/article/set?article_id=’ +obj.article_id,{ hits:parseInt(obj.hits) +1 });
}
5.3.5 闲置物品管理功能实现
管理员可审核和上下架用户发布的闲置物品,通过list_status字段控制前端显示。系统提供按标题、分类和店铺名称的搜索功能,并可批量删除违规物品。闲置物品管理界面如图5-23所示。
图5-23闲置物品管理界面
核心代码实现如下:
get_list_before(param) {
varuser_group=this.user.user_group;
if (user_group!= “管理员”) {
param[“sqlwhere”] = “(regular_user= ”+this.user.user_id+ ”)”;
}
return param;
}
checkInventory() {
letlowInventoryItems=this.list.filter(item =>item.cart_inventory< 5 &&item.cart_inventory>= 0);
if (lowInventoryItems.length> 0){this.inventoryDialogVisible= true; }
}
5.3.6 商品分类管理功能实现
管理员和普通用户均可通过商品分类管理功能对闲置物品的商品类型进行维护。该功能采用树形结构存储分类数据,通过father_id字段关联父子分类关系,支持无限级分类扩展。后端GoodsTypeController提供add和set方法实现对分类的增删改查操作,前端使用级联选择器组件展示多级分类层级,用户在发布闲置物品时可直接选择已建立的商品分类。删除分类前系统自动校验该分类下是否已关联商品,存在关联时阻止删除操作并提示用户。商品分类管理界面如图5-24所示。
图5-24商品分类管理界面
核心代码实现如下:
@PostMapping(“/add”)
@Transactional
public Map<String, Object>add(HttpServletRequestrequest) throwsIOException{
Map<String, Object>addMap=service.readBody(request.getReader());
checkParameter(addMap, “name”, “名称不能为空”);
this.service.insert(addMap);
returnsuccess(1);
}
buildTree(list,fatherId) {
const tree = [];
for (let item of list) {
if (item.father_id===fatherId) {
const children =this.buildTree(list,item.type_id);
tree.push({type_id:item.type_id, name:item.name, children:children });
}
}
return tree;
}
asyncdelInfo() {
for (leti= 0;i<list.length;i++) {
let res = awaitthis.get(“~/api/goods/get_list?”,{ type:type.name }); if (res.result&&res.result.list.length> 0){this.message.error(类型“${type.name}”下有关联的内容,无法删除!);
return;
}
}
awaitthis.delAll(list);
}
5.3.7 订单管理功能实现
管理员通过OrderController查看所有订单,支持按订单号、商品名称和状态搜索。可手动发货并分配配送员,系统自动生成配送单号并更新物流信息。订单管理界面如图5-25所示。
图5-25订单管理界面
核心代码实现如下:
get_list_before() {
if (this.user_group!== ‘管理员’) {
if (this.check_option(‘/goods/table’, ‘seller’)){this.url_get_list= “~/api/order/get_business_order_list?user_id=” +this.user.user_id; }} }logiFormSubmit(){this.post(“~/api/logistics_delivery/add?”,postData).then((json) => {
this.$post(“~/api/order/set?order_id=” +this.addLogiData.order_id,{delivery_state: “配送中”, state: “配送中” });
});
}
5.3.8 订单配送管理功能实现
管理员为订单分配配送员后,配送记录写入logistics_delivery表。配送员登录后查看分配的任务,更新配送状态。系统支持查询配送中的订单,并提供签收功能。订单配送管理界面如图5-26所示。
图5-26订单配送管理界面
核心代码实现如下:
deliveryStatusChange(data) {
this.post(“~/api/logistics_delivery/set?logistics_delivery_id=” +data.logistics_delivery_id,{delivery_status: “已完成”,signing_status: “待签收” }, (json) =>{this.post(“~/api/order/set?order_number=” +data.order_number,
{delivery_state: “已完成”, state: “待签收” });
});
}
5.3.9 订单售后管理功能实现
管理员查看售后申请列表,支持按订单号和售后状态筛选。点击审核后弹出对话框,通过updateExamineState方法将审核结果写入after_state字段,并填写回复内容。系统发送消息通知用户审核结果。订单售后管理界面如图5-27所示。
图5-27订单售后管理界面
核心代码实现如下:
assureVerify() {
this.post(“~/api/order_after_sale/set?order_after_sale_id=” +this.verifyItem[‘order_after_sale_id’],{ ‘after_state’:this.verifyForm.radio, ‘after_state_reply’:this.verifyForm.reply}, (json) =>{this.toast(“审核成功!”, ‘success’);
this.get_list();
});
}
5.3.10 举报反馈管理功能实现
管理员查看用户提交的举报反馈,未审核记录优先显示。通过updateExamineState方法审核,审核通过或未通过后状态更新,系统发送通知给举报用户。管理员可批量审核多条举报。举报反馈管理界面如图5-28所示。
图5-28举报反馈管理界面
核心代码实现如下:
@GetMapping(“/update_examine_state”)
public StringupdateExamineState(Long id, StringnewState) {
Map<String,String>queryMap= new HashMap<>();
queryMap.put(“id”,String.valueOf(id));
ReportFeedbackreport_feedback=service.findOne(queryMap);
report_feedback.setExamine_state(newState);
this.setEntity(queryMap,newHashMap<>(),report_feedback);
return “审核成功”;
}
asyncassureVerify() {
for (vari= 0;i<this.batchAllList.length;i++) {
awaitthis.$post(url,{examine_state:this.verifyItem.examine_state,examine_reply:this.verifyItem.examine_reply});}}
第六章 系统测试
6.1 测试目的
本次系统功能测试旨在验证校园二手交易平台各核心业务模块的功能完整性与正确性。测试范围涵盖闲置物品发布与上下架管理、订单生成与支付流程、订单配送状态流转、售后申请审核处理、闲置求购信息发布与检索、用户举报反馈处理以及管理员公告发布等关键业务流程。通过测试确认系统在不同用户角色权限下能够正确执行业务操作,数据能够准确持久化存储,状态流转符合业务规则。测试目的在于发现系统中可能存在的功能缺陷与逻辑错误,保障系统上线后的稳定运行与用户体验。
6.2 测试方法
采用黑盒测试方法,针对校园二手交易平台的各功能模块设计测试用例。测试过程覆盖普通用户前台、普通用户后台及管理员后台三大角色权限范围。测试执行依据预设的测试用例,按照业务流程逐项验证功能正确性。测试环境配置与开发环境保持一致,数据库采用MySQL进行数据持久化存储。测试数据由测试人员模拟真实业务场景生成,包含用户注册信息、商品发布数据、订单交易记录等。功能验证通过观察前端界面反馈、后端接口返回及数据库记录变化三个维度综合判断,确保系统各项功能符合预期设计要求。
6.3 测试内容
系统功能测试选取闲置物品发布、订单生成与支付、订单配送状态流转、售后申请审核、闲置求购发布、举报反馈处理以及通知公告发布七个核心业务模块进行验证。这些模块覆盖了二手交易平台从商品上架、交易达成、物流配送、售后服务到信息反馈的完整业务闭环。
闲置物品发布测试如表6-1所示。
表6-1闲置物品发布测试用例表
| 闲置物品发布 | 发布商品信息的完整性验证 | 填写商品标题、价格、图片及描述后提交 | 商品成功发布并显示于商品列表 | 符合预期 | 测试成功 |
| 闲置物品发布 | 商品上下架状态切换验证 | 将已发布商品状态修改为下架 | 商品在前端列表不再显示 | 符合预期 | 测试成功 |
| 闲置物品发布 | 商品信息编辑更新验证 | 修改已发布商品的价格或描述信息 | 前端详情页显示更新后的信息 | 符合预期 | 测试成功 |
订单生成与支付测试如表6-2所示。
表6-2订单生成与支付测试用例表
| 订单生成与支付 | 用户下单流程验证 | 将商品加入购物车后提交订单 | 系统生成订单并跳转至支付页面 | 符合预期 | 测试成功 |
| 订单生成与支付 | 订单状态变更验证 | 完成订单支付操作 | 订单状态从待付款变更为待发货 | 符合预期 | 测试成功 |
| 订单生成与支付 | 订单取消功能验证 | 在待付款状态下取消订单 | 订单状态变更为已取消且商品库存恢复 | 符合预期 | 测试成功 |
订单配送状态流转测试如表6-3所示。
表6-3订单配送状态流转测试用例表
| 订单配送状态流转 | 商家发货操作验证 | 商家对待发货订单执行发货操作 | 订单状态变更为配送中并生成配送单号 | 符合预期 | 测试成功 |
| 订单配送状态流转 | 配送员状态更新验证 | 配送员将配送状态更新为已完成 | 订单状态变更为待签收 | 符合预期 | 测试成功 |
| 订单配送状态流转 | 用户确认收货验证 | 用户对待签收订单执行确认收货 | 订单状态变更为已完成 | 符合预期 | 测试成功 |
售后申请审核测试如表6-4所示。
表6-4售后申请审核测试用例表
| 售后申请审核 | 用户发起售后申请验证 | 对已完成订单提交售后申请并填写内容 | 系统生成售后记录且状态为未审核 | 符合预期 | 测试成功 |
| 售后申请审核 | 管理员审核通过验证 | 管理员对售后申请执行审核通过操作 | 售后状态变更为已通过且订单状态更新 | 符合预期 | 测试成功 |
| 售后申请审核 | 管理员审核驳回验证 | 管理员对售后申请执行审核不通过操作 | 售后状态变更为未通过并填写驳回理由 | 符合预期 | 测试成功 |
闲置求购发布测试如表6-5所示。
表6-5闲置求购发布测试用例表
| 闲置求购发布 | 求购信息提交验证 | 填写求购物品名称、描述及期望价格后提交 | 求购信息成功发布并展示于求购列表 | 符合预期 | 测试成功 |
| 闲置求购发布 | 求购信息检索验证 | 按物品名称关键词进行搜索 | 返回包含该关键词的求购信息列表 | 符合预期 | 测试成功 |
| 闲置求购发布 | 求购信息删除验证 | 用户删除自己发布的求购信息 | 该信息从求购列表中移除 | 符合预期 | 测试成功 |
举报反馈处理测试如表6-6所示。
表6-6举报反馈处理测试用例表
| 举报反馈处理 | 用户提交举报验证 | 对违规商品填写举报原因并提交 | 系统生成举报记录且状态为未审核 | 符合预期 | 测试成功 |
| 举报反馈处理 | 管理员处理举报验证 | 管理员查看举报内容后执行处理操作 | 举报状态变更为已处理且被举报商品下架 | 符合预期 | 测试成功 |
| 举报反馈处理 | 举报结果通知验证 | 管理员处理完成后系统发送通知 | 用户收到举报处理结果通知 | 符合预期 | 测试成功 |
通知公告发布测试如表6-7所示。
表6-7通知公告发布测试用例表
| 通知公告发布 | 公告发布功能验证 | 管理员填写公告标题和正文后发布 | 公告成功发布并展示于首页公告栏 | 符合预期 | 测试成功 |
| 通知公告发布 | 公告编辑更新验证 | 修改已发布公告的标题或正文内容 | 前端公告详情页显示更新后的内容 | 符合预期 | 测试成功 |
| 通知公告发布 | 公告删除功能验证 | 管理员执行公告删除操作 | 该公告不再显示于公告列表 | 符合预期 | 测试成功 |
测试结论
本次系统功能测试一共执行了七个主要的业务模块的测试用例,全部通过了验证。闲置物品发布模块的用户发布、上下架切换、信息修改等均可以正常使用。订单生成和支付模块中下单、支付、取消订单的流程都达到预期的效果,订单状态会正确更新。订单配送状态流转模块中发货、配送状态的更新以及用户的确认收货等操作均可以顺利完成。售后申请审核模块中用户发起售后、管理员审核通过和驳回的操作都完成了,售后状态正确地更新了。闲置求购发布模块中的求购信息提交、关键词检索、删除等功能都工作正常。举报反馈处理模块中用户提交举报、管理员处理和结果通知的流程均能正常进行。通知公告发布模块中的公告发布、编辑修改和删除功能都正确实现了。
项目分享:大家可自取用于参考学习,获取方式可私信哦!




