摘 要
传统的周边交易大多依靠综合性电商平台,存在商品分类杂乱无章、缺少专门针对某款游戏资产的交易服务等情况,不能很好地满足玩家对于虚拟武器、皮肤这些数字化模型进行精细化管理并实现交易的需求。为了弥补该市场的空白,创建一个专业的交易平台有重大的现实意义。本系统基于B/S架构,采用Spring Boot作为后端框架、Vue作为前端技术,并结合MySQL数据库,在IntelliJ IDEA环境中完成开发。系统主要针对三大类型用户建立了完整的功能体系。普通用户可以浏览游戏商城中的商品,可以将喜欢的商品添加到购物车中进行购买,也可以查看自己的订单并发表对已购买商品的评价,还可以管理个人店铺的信息。商家模块包含店铺信息修改,商城商品上架与下架,商品分类设置,订单处理以及售后问题解决等各个环节的操作。管理员是最高层次的游戏分类者、等级划分者、店铺信息审查员、商城监管人和最后解决用户投诉的人。系统界面简洁,操作流程清晰。通过实践证明,系统可以打通商品发布、交易和售后服务评价等所有环节,实现对游戏武器模型交易信息进行结构化、流程化的管理,给玩家提供了一个安全便捷的垂直交易通道,有效地提高了该类商品的交易效率以及信息透明度。
关键词:游戏武器模型,Spring Boot,Vue.js,交易系统,MySQL
Abstract
Traditional peripheral trading mostly relies on comprehensive e-commerce platforms, which have issues such as chaotic product classifications and a lack of trading services specifically targeted at certain game assets. As a result, they cannot effectively meet players' needs for refined management and trading of digital models like virtual weapons and skins. To fill this gap in the market, creating a professional trading platform has significant practical significance. This system is based on the B/S architecture, usingSpring Bootas the backend framework and Vue as the frontend technology, combined with a MySQL database, and developed in the IntelliJ IDEA environment. The system establishes a complete functional system for three main types of users. Regular users can browse products in the game mall, add their favorite items to the shopping cart for purchase, view their orders and post reviews on purchased products, and manage information about their personal stores. The merchant module includes operations such as modifying store information, listing and delisting mall products, setting product categories, processing orders, and resolving after-sales issues. Administrators are the highest-level game classifiers, rank organizers, store information reviewers, mall supervisors, and the final resolvers of user complaints. The system interface is simple, and the operation process is clear. Practical application has shown that the system can integrate all stages of product listing, trading, and after-sales service evaluation, achieving structured and streamlined management of game weapon model trading information. It provides players with a safe and convenient vertical trading channel, effectively improving the transaction efficiency and information transparency of such products.
Key words:Game Weapon Models, Spring Boot, Vue.js, Trading System, MySQL.
第一章 绪论
1.1 研究背景与意义
游戏武器模型是数字娱乐消费的重要部分,游戏武器模型的交易方式一直存在,在通用电商平台上以及玩家之间进行私人的交易。传统的线下转账交易和论坛发帖方式存在着信息不对称严重、交易过程无监管、商品真假难辨、售后维权难等问题[1]。早期的游戏论坛虽然开辟了交易区,但是碎片化的信息呈现方式以及滞后的内容更新机制,造成好的武器模型很难沉淀下来,玩家的购买效率低。现有的综合性平台商品分类过于粗糙,不能很好地对应虚拟道具的特点,玩家对于交易的及时性、社区间的互动以及个性化的推荐等深层次的需求很难得到满足[2]。
开发出专业的游戏武器模型销售系统之后,可以将商品展示、在线交易、订单追踪和售后服务评价等各个环节有机地串联起来,从而大大提高某类数字商品的流通速度以及透明度。有利于规范游戏衍生品交易流程,减少由于信息壁垒造成的交易纠纷,给玩家营造出一个安全、可靠的垂直交易环境。同时系统对于用户的分权管理以及店铺经营机制的加入,给类似兴趣电商类平台提供了一种可行的运作方式。
1.2 国内外研究现状
国内游戏虚拟物品交易随着网络游戏的发展而不断变化。早期以5173等游戏交易平台为主,采用寄售、担保交易方式来解决点卡和基础装备的流通问题。之后淘宝等综合性平台开设游戏专区,借助成熟的支付系统扩大了交易途径,但是对虚拟商品的属性表述以及交付流程缺少标准化的支持[3]。贴吧、游戏论坛等社区成了玩家自生交易的信息汇集地,但是高互动性并没有掩盖它信息结构化程度低、交易成功率不稳定的特点[4]。近几年来,由于Steam社区市场、网易藏宝阁等官方交易系统出现,使得某些游戏的武器和饰品交易同游戏账号实现深度绑定,交易的安全性得以提高,但是跨游戏、跨平台的综合交易需求仍然由第三方聚合类网站或者App来完成[5]。这些聚合平台把各种各样的信息进行汇总,并且给出比较价格的服务,在交易的担保、售后服务的仲裁以及用户的社交关系创建方面还处在探索之中[6]。国内的相关研究也由原来的重视交易系统的技术实现,转而开始探究虚拟财产的保护、用户的信任以及社区生态的治理等问题[7]。
国外的游戏武器模型交易市场同数字发行平台以及玩家社群之间关系更加密切。Valve公司推出的Steam社区市场是第一个将游戏内置交易和第三方开发者生态相结合的游戏市场,玩家可以在平台上直接购买或者出售《反恐精英》等游戏中的皮肤饰品,并且平台会对所有的交易进行严格的审核以及对过往的交易进行查询[8]。以Bleacher Report为代表的体育类游戏和衍生品资讯平台,在早期主要进行编辑内容的制作,后来开始加入用户的评论以及论坛的功能,给游戏武器等虚拟资产的讨论打下了社区的基础[9]。数据聚合平台SofaScore和Onefootball主要为用户提供赛事数据以及球员的动态信息,并且通过商业合作的方式推广虚拟道具给游戏发行商[10]。欧洲各个足球俱乐部的官方应用软件将球队信息、商城、球迷社区三者结合在一起,使球迷可以买到官方授权的数字收藏品以及游戏中所需要的游戏道具,在完成这一过程之后,就已经实现了从内容消费到虚拟商品交易的转型[11]。Fantasy Premier League等玩法平台依靠游戏化手段调动玩家对于球员虚拟卡牌的搜集和买卖积极性,背后支撑的是不断更新的赛事数据系统以及完备的用户付费制度[12]。
1.3 主要研究内容
本文研究并开发出一款使用Spring Boot和Vue.js的武器模型销售管理系统。系统主要面向玩家、商家和平台管理员提供垂直化数字商品交易服务,以普通用户的商品浏览购买评论、商家的店铺和订单管理、管理员的分类审核和售后仲裁这三种角色为中心来构建功能体系。研究工作按照软件工程的规范来执行,即先做需求分析,再进行系统架构的设计,接着是功能模块的划分,然后是数据库的设计以及编码实现和测试验证。系统使用前后端分离的B/S架构,前端用Vue.js创建交互界面,后端用Spring Boot实现业务逻辑支持,MySQL做数据存储工作。最终达到游戏商城、订单处理、店铺信息管理、多级分类维护和售后管理等主要目的,重点解决游戏武器模型交易过程中信息分散、流程监管不到位等问题。
第二章 相关技术介绍
2.1 Spring Boot框架
Spring Boot是用Java语言编写的开源微服务框架,它的设计目的就是简化Spring应用的初始搭建和开发工作。它依靠自动配置的方式,依照项目的依赖情况来挑选恰当的组件,从而大幅度削减开发者对于配置文件的直接操作。内嵌的Tomcat、Jetty等Servlet容器使得应用程序可以作为一个独立运行的JAR包存在,而不再是需要进行War文件部署的传统模式下使用的应用环境。框架的核心是遵循约定优于配置的原则,在Spring生态中为各种模块提供开箱即用的支持,开发者只需要关注业务逻辑代码的实现。在运行时,Spring Boot根据启动类加载所有的条件注解,扫描当前类路径下的依赖库,并生成相应的bean定义,最后启动内嵌容器监听指定的端口等待客户端的请求[13]。控制层接收到前端发出的HTTP请求之后,按照路由映射将请求分发到相应的Service层进行处理,Service层会调用Repository层以及数据库来执行数据操作,并最终把处理后的结果一层层地传回给客户端。完整的调用链将各个层的功能分清楚,保证后端服务具有良好的可维护性和扩展性。本系统用Spring Boot搭建了后端核心,使用依赖注入的方式对用户服务、订单处理和商品管理等模块进行组件的实例化,并且以REST风格的接口给前端提供稳定的支撑数据。
2.2 Vue.js框架
Vue.js是创建用户界面的一种渐进式JavaScript框架,主要库只关注视图层,使用自下而上增量开发的方式进行构建。框架采用组件化开发方式,把页面拆分成一个个可以被复用的独立组件,每一个组件都包含有自己的模板、脚本以及样式,组件树结构清楚地体现出用户界面的层次结构[14]。Vue.js利用响应式数据绑定的方式把数据模型同视图层联系起来,当数据对象发生改变的时候,框架内部会使用Object.defineProperty或者Proxy对数据进行拦截,并且收集所有相关的依赖项,再创建一个异步更新队列,最后只对最细小的DOM节点执行一次更新。单文件组件把模板、逻辑和样式放在一起写在一个文件里,使代码更加内聚,也更容易阅读。路由管理器VueRouter可以实现嵌套路由以及动态路由的匹配,在不同的URL下,会展示不同的视图组件而不需要重新加载整个页面。本系统的前端界面使用Vue.js进行开发,根据用户的角色来划分出商城浏览、订单管理、店铺设置等不同的功能模块,并且利用组件通信的方式将用户的操作指令传送给后台接口,然后通过Axios库去发起异步请求到后端获取数据,最后再由页面自动生成相应的元素以达到良好的交互效果。
2.3 MySQL数据库
MySQL属于业界广泛使用的、关系型的数据库管理系统,它的数据处理是以结构化的查询语言为依托的。数据库用客户端/服务器结构来实现,服务器端用来保存、查询和操控数据,客户端则借助连接去发出SQL命令,并获取执行的结果。InnoDB存储引擎是MySQL的默认存储引擎,可以对行进行锁,也可以设置外键约束,在高并发的情况下保证数据的一致性、完整性。事务管理符合ACID原则,用日志系统来记载所有的数据变动,在系统出现异常情况时依靠重做日志和撤销日志回到一致的状态。数据表的设计符合范式理论来减少冗余,用主键索引和二级索引来加快查询响应速度,执行计划优化器对SQL语句进行分析之后选择成本最小的访问路径得到数据行[15]。数据库连接池模块保存着一组持久化的连接供应用反复利用,从而削减频繁创建和销毁连接所造成的性能损耗。本系统用MySQL来存储用户的档案、商品的信息、订单以及评论的内容等主要业务数据,并且按照各个实体之间的联系创建出合适的表结构,使用外键来保证数据的参照完整性和性能的提升,在高频查询的时候对索引进行优化。
2.4 前后端分离架构
前后端分离架构是把用户界面和业务逻辑分开的一种软件设计模式,它的主要思想就是确定清楚的交互界限。前端主要完成页面渲染、捕捉用户的事件以及管理界面的状态,而后台主要是进行业务规则的处理、数据的持久化和安全认证等操作,并且会使用标准接口协议来与其他系统交互。浏览器加载前端应用之后,JavaScript代码异步调用后端发布的HTTP接口,带入需要的数据参数,接口返回JSON或者XML格式的响应内容,前端解析之后更新视图展示给用户。该种交互方式使前端和后端能够分别独立地完成开发、部署与扩展的工作,前端用工程化的方法来完成资源打包及热更新,而后端主要是对服务做粒度上的划分,并提高它的性能。在部署阶段把静态资源放在CDN或者Web服务器上,动态接口放到应用服务器集群里,流量入口用网关统一路由和过滤[16]。本系统全部使用前后端分离的方式进行开发,Vue.js工程构建出的页面通过代理将请求转发到Spring Boot服务上,登录令牌被保存在请求头里来保持会话的状态,服务端只提供纯数据负载,并且所有的界面跳转都是由前端路由控制完成的,从而减轻了服务器端模板渲染的工作量并且提高了系统的响应速度[17]。
第三章 系统分析
3.1 功能需求分析
3.1.1 普通用户功能
普通用户可以在系统中浏览到游戏商城里所有的武器模型,点击商品详情页之后就可以把想要的商品添加进购物车,并且可以完成支付动作。用户进入我的订单模块可以跟踪订单的状态,对于已经完成的交易可以发表商品评论来表达自己的使用感受。用户可以浏览店铺信息页面,了解自己关注或者购买过的商品所对应的商家信息。普通用户用例图如下图3-1所示。
图3-1普通用户用例图
3.1.2 商家功能
商家登录系统之后可以对自身的店铺基本信息进行管理,即店铺简介、联系信息和经营资质等。商家利用游戏商城管理模块来上架、下架以及调整自有商品的库存,并且用分类列表功能把商品归入不同的类别中。商家在订单列表管理中查看用户提交的订单、处理发货等操作,对用户发起的售后申请用订单售后管理模块进行退款或者换货。商家角色的用例图如下图3-2所示。
图3-2商家用例图
3.1.3 管理员功能
管理员对整个系统的后台进行控制,使用游戏分类管理功能来设置武器模型所属的类别,用等级分类管理功能来区分武器品级。分类列表管理模块给管理员提供查看和修改所有的已经建立好的分类,店铺信息管理模块用来审核商家提交的店铺资料。管理员对游戏商城中的所有商品展示状态进行监控,订单售后管理模块解决商家和用户因不能达成一致而产生的售后问题。管理员的用例图如下图3-3所示。
图3-3管理员用例图
3.2 可行性分析
3.2.1 操作可行性
系统界面布局参照主流电商平台的设计,普通用户浏览商品、加购购物车、提交订单时可以按照以往的网购习惯进行操作。商家用户从店铺管理入口开始对商品信息、订单状态等进行修改,操作路径明确,功能按钮的位置固定。管理员后台用分层导航来管理各种控制手段,在商家资料审核以及售后问题处理上都放在不同的页面中。系统上线之后用户不需要再进行额外的培训就可以开始使用,原有的线下或者通过社交软件交易的方式被集中化的平台所取代,订单的状态也得到了即时的更新,从而降低了沟通的成本。运维人员可以通过后台的日志监控系统来获取系统的运行状况,并且可以迅速找到出现的用户问题并加以解决。因此系统的操作是可行的。
3.2.2 市场可行性
游戏武器模型属于数字商品在游戏玩家当中存在着比较稳定的需求量,目前的玩家大多借助贴吧发帖、QQ群交流或者第三方担保平台来达成交易,这样的交易模式存在着信息散乱、交易过程缺乏监管以及售后服务难于解决等状况。主要面向大量端游、手游用户,一些玩家会出于对稀有武器皮肤的收集癖和买高端属性装备的习惯而不断进行消费。本系统给玩家搭建起一个集中化的商品展示和在线交易的平台,给商家创建了一个规范的商品管理后台,并且加入了平台审核这一环节来保证交易的安全性。相比于现有的分散交易方式来说,在商品分类细致程度以及交易过程的闭环性上,该系统有着明显的优点,可以促使那些对交易速度和安全有需求的用户向平台转移。因此,在市场上是可行的。
3.2.3 社会可行性
系统的设计和实现都符合目前的法律规定,即对于网络交易以及个人隐私的保护。用户注册和登录时收集必要的信息,并且对使用目的做出说明,密码等敏感数据用加密的方式保存起来以避免泄露。商品信息发布内容由商家自行上传,管理员对违规内容进行审核删除,防止出现违法或者不良信息的传播。系统投入运行之后给玩家创建起标准化的数字商品交易场所,交易记录得以追踪,从而减小了虚拟财产纠纷出现的可能性。平台的运行不会给现有的社会秩序带来冲击,而会以流程透明化的方式推动交易双方建立起信任的关系。所以系统在社会上是可行的。
第四章 系统设计
4.1 系统架构设计
系统使用模块化分层结构进行设计,前端交互层用Vue.js框架搭建用户操作界面,并且用Axios库异步向后端服务器发起HTTP请求。后端业务逻辑层使用的是Spring Boot,接收到请求之后再经过控制器的路由分发到服务层进行具体的业务处理,即商品搜索、下单、评论发表等主要的操作。数据持久化层使用MySQL数据库来保存所有的业务数据,并且用Repository层和Service层进行数据的交互。本地缓存模块用来存储热点商品信息和用户的会话状态,减小数据库的访问量。前端交互涉及商城浏览、购物车管理、订单查询等界面,后端业务逻辑处理交易流程和权限验证,数据持久化保证用户档案和交易记录的同步,本地缓存加快页面响应速度。系统整体架构图如图4-1所示。
图4-1系统架构图
4.2 系统结构功能设计
根据系统中的三种用户角色来创建功能模块。普通用户可以浏览游戏商城中的武器模型,将商品添加到购物车中之后提交订单,在个人中心查看订单的状态并发表对已经购买的商品的评价。商家登录系统之后可以修改店铺信息、添加或删除商品上下架和分类表单、处理用户的订单及发货业务以及对售后申请进行审核。管理员对后台控制,设置游戏类别、等级分类标准,审查商家递交的店铺资料和商品信息,解决商户同顾客之间不能达成协议的售后服务问题。该系统的功能结构如图4-2所示。
图4-2系统功能结构图
4.3 系统流程设计
总体业务流程图设计
系统总体业务流程是从用户登录或者注册开始的。普通用户在游戏商城浏览武器模型,选择一个模型后下单。商家登录系统接收到订单之后会进行发货操作。用户收到商品之后,可以对商品进行评价。用户发起售后申请后,商家先进行审核处理,不能达成一致的再由管理员介入仲裁。总体业务流程如下图4-3所示。
图4-3总体业务流程图
购买商品流程设计
用户进入游戏商城浏览武器模型列表的时候,如果想要查看某一个商品的详细信息,只需要点击该商品所在的卡片即可。确认商品规格和库存之后再选择加入购物车或者立即购买。跳转到订单确认页面填写收货信息,提交订单之后系统产生待支付订单。用户执行完支付后,订单状态就会变为待发货。购买商品的流程如图4-4所示。
图4-4购买商品流程图
订单处理流程设计
商家登录之后进入订单列表管理模块,可以查看所有的待处理订单。选择需要发货的订单点发货按钮,输入物流信息后提交给系统。用户端订单状态由待签收改为待签收。用户收到商品之后,订单状态就变成已完成了。用户提交退回应求的时候,商家会进入到售后模块进行处理。订单处理流程见图4-5。
图4-5订单处理流程图
售后审核流程设计
用户在订单页面选择已经支付的订单后发起售后申请,填写售后类型和申请理由,并上传凭证。商家收到售后通知之后查看申请内容,根据实际情况做出是否通过或者拒绝的决定。审核通过之后系统执行退款操作,把资金退还给用户。若商家拒绝用户可申请管理员介入仲裁。售后服务审核流程如图4-6所示。

图4-6售后审核流程图
商品管理流程设计
商家登录系统之后进入游戏商城管理模块,单击添加商品按钮输入武器模型信息即标题、分类、等级、价格和库存。上传商品主图和详细信息之后提交审核。管理员在后台对商品进行审核,审核通过的商品才会被上架到游戏商城。用户端可以浏览此商品。商品管理流程图如下图4-7所示。

图4-7商品管理流程图
4.4 数据库设计
数据库设计属于系统开发的基础工作,关系型模型用二维表来组织数据,可以很好地保持实体之间的联系以及数据的一致性[18]。规范化的准则来制定表结构的设计方案,从而达到减小数据重复出现的目的,并且防止出现更新错误的情况发生。本系统中的数据库用来保存用户的档案、商品的信息、订单和评论的内容等各方面的信息,用主键约束和外键联系保证数据的一致性。事务管理保证了订单产生和支付动作是原子性的,在多步写入的时候不会出现数据不一致的情况[19]。
4.4.1 概念设计
商家用户实体主要是包含商家姓名、联系电话、资质认证、审核状态等属性的表。商家用户实体属性图如下图4-8所示。

图4-8商家用户实体属性图
普通用户的实体主要是包含用户姓名、手机号码、审核状态等属性的表。普通用户实体属性图如下图4-9所示。

图4-9普通用户实体属性图
游戏商城的实体主要是商品标题、游戏类型、武器等级、卖价、商品库存、上架状态这些属性。游戏商城实体属性图如下图4-10所示。
图4-10游戏商城实体属性图
订单实体包含订单号,商品标题,价格,数量,订单状态,买家编号,商家编号等。订单实体属性图如下图4-11所示。
图4-11订单实体属性图
订单售后实体包含订单号、售后类型、售后状态、售后内容、买家编号、商家编号等属性。订单售后实体属性图如下图4-12所示。
图4-12订单售后实体属性图
店铺信息实体包含店铺名称、店铺电话、店铺封面、店铺描述、商家用户、保证金这些属性。店铺信息实体属性图如下图4-13所示。
图4-13店铺信息实体属性图
游戏分类实体主要是游戏类型、创建者等信息。游戏分类实体属性图如下图4-14所示。

图4-14游戏分类实体属性图
等级分类实体主要是包含等级类型、创建用户这些属性的。等级分类实体属性图如下图4-15所示。

图4-15等级分类实体属性图
评论实体有评论内容、评论人编号、来源编号、来源表等字段。评论实体属性图如图4-16所示。
图4-16评论实体属性图
购物车实体主要是包含商品编号、数量、单价、用户编号这些属性的实体。购物车实体属性图如下图4-17所示。

图4-17购物车实体属性图
系统E-R图如图4-18所示。
图4-18系统E-R图
4.4.2 数据库表设计
商家用户表主要是存放商家账号的相关数据。主要是商家的姓名、电话号码、资质认证和审核状态等。见表4-1。
表4-1商家用户表
| 1 | business_user_id | int | 11 | 是 | 是 | 商家用户ID |
| 2 | business_name | varchar | 64 | 是 | 否 | 商家姓名 |
| 3 | contact_number | varchar | 16 | 是 | 否 | 联系号码 |
| 4 | qualification_certification | varchar | 255 | 否 | 否 | 资质认证 |
| 5 | examine_state | varchar | 16 | 是 | 否 | 审核状态 |
| 6 | user_id | int | 11 | 是 | 否 | 用户ID |
普通用户表主要是存放备用用户的个人信息。主要是用户姓名、手机号码、审核状态等。见表4-2。
表4-2普通用户表
| 1 | ordinary_user_id | int | 11 | 是 | 是 | 普通用户ID |
| 2 | user_name | varchar | 64 | 否 | 否 | 用户姓名 |
| 3 | mobile_phone_number | varchar | 16 | 否 | 否 | 手机号码 |
| 4 | examine_state | varchar | 16 | 是 | 否 | 审核状态 |
| 5 | user_id | int | 11 | 是 | 否 | 用户ID |
游戏商城表主要是用来保存商家发布的武器模型商品信息。商品包括标题、游戏类型、武器等级、售价、商品库存和上架情况这六个字段。见表4-3。
表4-3游戏商城表
| 1 | game_mall_id | int | 11 | 是 | 是 | 游戏商城ID |
| 2 | cart_title | varchar | 125 | 否 | 否 | 标题 |
| 3 | game_type | varchar | 64 | 否 | 否 | 游戏类型 |
| 4 | weapon_level | varchar | 64 | 否 | 否 | 武器等级 |
| 5 | cart_price | double | – | 是 | 否 | 卖价 |
| 6 | cart_inventory | int | 11 | 是 | 否 | 商品库存 |
| 7 | list_status | smallint | 6 | 否 | 否 | 上架状态 |
订单表主要是用于保存用户的交易记录。主要包含订单号、商品标题、价格、数量、订单状态、买家编号、商家编号等字段。如表4-4所示。
**
表4-4订单表
| 1 | order_id | int | 11 | 是 | 是 | 订单ID |
| 2 | order_number | varchar | 64 | 否 | 否 | 订单号 |
| 3 | title | varchar | 255 | 否 | 否 | 商品标题 |
| 4 | price | double | – | 是 | 否 | 价格 |
| 5 | num | int | 11 | 是 | 否 | 数量 |
| 6 | state | varchar | 16 | 是 | 否 | 订单状态 |
| 7 | user_id | int | 11 | 是 | 否 | 买家编号 |
| 8 | merchant_id | mediumint | 9 | 是 | 否 | 商家编号 |
订单售后表主要是保存用户发起的售后申请信息。主要是包含订单号、售后类型、售后状态、售后服务内容、买家编号、商家编号等信息的表单。见表4-5。
表4-5订单售后表
| 1 | order_after_sale_id | int | 11 | 是 | 是 | 订单售后ID |
| 2 | order_number | varchar | 64 | 否 | 否 | 订单号 |
| 3 | type | varchar | 255 | 否 | 否 | 售后类型 |
| 4 | after_state | varchar | 16 | 否 | 否 | 售后状态 |
| 5 | content_desc | varchar | 255 | 否 | 否 | 售后内容 |
| 6 | user_id | int | 11 | 是 | 否 | 买家编号 |
| 7 | merchant_id | mediumint | 9 | 是 | 否 | 商家编号 |
店铺信息表主要是用来保存商家店铺的相关信息。主要是店铺名称、店铺电话、店铺封面、店铺描述、商家用户、保证金等字段。表4-6为数据结果。
表4-6店铺信息表
| 1 | store_information_id | int | 11 | 是 | 是 | 店铺信息ID |
| 2 | shop_name | varchar | 64 | 否 | 否 | 店铺名称 |
| 3 | shop_phone | varchar | 64 | 否 | 否 | 店铺电话 |
| 4 | shop_cover | varchar | 255 | 否 | 否 | 店铺封面 |
| 5 | store_description | text | 65535 | 否 | 否 | 店铺描述 |
| 6 | business_user | int | 11 | 否 | 否 | 商家用户 |
| 7 | margin | double | – | 否 | 否 | 保证金 |
游戏分类表主要是用来保存武器模型属于哪一类游戏。主要有游戏类型、创建者等。见表4-7。
表4-7游戏分类表
| 1 | game_categories_id | int | 11 | 是 | 是 | 游戏分类ID |
| 2 | game_type | varchar | 64 | 是 | 否 | 游戏类型 |
| 3 | create_by | int | 11 | 是 | 否 | 创建用户ID |
等级分类表主要用来存放武器模型的品级。主要包含等级类型、创建用户等信息。见表4-8。
表4-8等级分类表
| 1 | grade_class_nameification_id | int | 11 | 是 | 是 | 等级分类ID |
| 2 | class_name_type | varchar | 64 | 是 | 否 | 等级类型 |
| 3 | create_by | int | 11 | 是 | 否 | 创建用户ID |
评论表主要是用来保存用户对于已经购买的商品的评价内容。包含评论内容、评论人编号、来源编号和来源表这些字段。见表4-9。
表4-9评论表
| 1 | comment_id | int | 11 | 是 | 是 | 评论ID |
| 2 | content | longtext | 4294967295 | 否 | 否 | 内容 |
| 3 | user_id | int | 11 | 是 | 是 | 评论人编号 |
| 4 | source_id | int | 11 | 是 | 否 | 来源编号 |
| 5 | source_table | varchar | 255 | 否 | 否 | 来源表 |
购物车表主要是用来保存用户暂时存放的待购商品信息。主要包含商品编号、数量、单价、用户编号等字段。如表4-10所示。
**
表4-10购物车表
| 1 | cart_id | int | 11 | 是 | 是 | 购物车ID |
| 2 | goods_id | mediumint | 9 | 是 | 是 | 商品编号 |
| 3 | num | int | 11 | 是 | 否 | 数量 |
| 4 | price | double | – | 是 | 否 | 单价 |
| 5 | user_id | int | 11 | 是 | 否 | 用户编号 |
第五章 系统实现
5.1 普通用户功能实现
5.1.1 游戏商城功能实现
用户进入游戏商城模块之后,系统从数据库中查询所有的上架商品,并用列表的形式展示出来。商品卡片是武器的模型名字、游戏类型、等级类别以及价格等。用户点击任意一张卡片,就跳转到详情页去查看全部的介绍以及多张商品图片。游戏商城界面如下图5-1所示。
图5-1游戏商城界面
5.1.2 购买商品功能实现
用户在商品详情页输入武器模型的规格和库存数量之后,再点入加入购物车按钮,使该件商品被暂存在购物车内。购物车页面汇总用户选择的多件商品,用户勾选需要结算的商品之后点击去结算按钮,进入订单确认页面填写收货信息并提交订单。购买商品界面如图5-2所示。
图5-2购买商品界面
5.1.3 我的订单功能实现
用户点击底部导航栏我的订单入口进入订单列表页面。系统按照时间倒序的方式展示用户所提交的所有的订单,每个订单卡片上都显示了该订单的状态,即待付款、待发货或者已完成。用户点击卡片查看订单详情,对于处于待付款状态的订单可以进行取消操作。我的订单界面如下图5-3所示。
图5-3我的订单界面
5.1.4 发表商品评论功能实现
用户在订单列表里找到状态是已完成的订单之后,就会被引导到评论编辑页面上进行评价。页面显示商品的缩略图和标题,在输入框中填入用户对于武器模型真实感受之后,再点击提交按钮。评论内容经后端保存到数据库中,再在前端商品详情页的评论栏中显示出来。发表商品评论界面如下图5-4所示。
图5-4发表商品评论界面
5.1.5 店铺信息功能实现
用户从商品详情页中的店铺链接或者店铺搜索入口进入店铺信息页面。页面展示店铺名、店铺评分为五颗星、店铺电话及店铺详情介绍。用户可以查看本店发布的所有商品,然后做出继续浏览或者购买的选择。店铺信息页面图5-5。
图5-5店铺信息界面
5.2 商家功能实现
5.2.1 店铺信息管理功能实现
商家登录系统之后就可以进入到店铺信息管理模块,在该模块中可以查看到当前店铺的封面图、店铺名称、联系电话以及保证金的状态。商家点击编辑按钮对店铺的简介或者联系信息进行修改,修改的内容提交之后会经过管理员的审核。店铺信息管理系统如图5-6所示。
图5-6店铺信息管理界面
5.2.2 游戏商城管理功能实现
商家可以在游戏商城管理模块中看到本店发布的所有武器模型商品。页面顶部有新增商品按钮,点击之后会跳转到商品发布页面填写标题、分类、等级、价格和库存信息。商家可以对已经上架的商品进行下架操作。游戏商城管理界面如下图5-7所示。
图5-7游戏商城管理界面
5.2.3 分类列表管理功能实现
商家进入到分类列表管理模块之后,就会看到自己所用的店铺的商品分类树形结构。页面有添加分类的按钮,商家点进去之后输入分类名和上级分类。已经添加的分类可以进行修改名称或者删除的操作。分类列表管理界面如下图5-8所示。
图5-8分类列表管理界面
5.2.4 订单列表管理功能实现
商家点击订单列表管理入口进入订单处理页面,按照下单时间顺序显示用户提交的订单。订单卡片的状态是待发货或者已完结。商家在确认订单信息无误之后点击发货按钮,并输入对应的物流单号,然后将订单状态更改为待签收。订单列表管理界面如下图5-9所示。
图5-9订单列表管理界面
5.2.5 订单售后管理功能实现
商家可以查看自己发布的商品的订单售后管理页面,也可以在该页面下对用户的售后申请进行处理。页面显示售后单号、申请类型和申请原因。商家点击审核按钮查看申请详情,选择通过或者拒绝的操作,审核结果用站内信的方式通知用户。订单售后服务界面如图5-10所示。
图5-10订单售后管理界面
5.3 管理员功能实现
5.3.1 游戏分类管理功能实现
管理员登录后台进入游戏分类管理模块,可以看见所有的已经创建的游戏类型。管理员单击新增分类按钮输入游戏名称,已经存在的分类支持编辑名称或者删除操作。分类信息更新之后,前端商城页面游戏筛选条件也会随之发生变化。游戏分类管理界面如下图5-11所示。
图5-11游戏分类管理界面
5.3.2 等级分类管理功能实现
管理员对等级分类管理模块中的武器模型品级划分系统做相应的调整工作。页面展示等级名称列表,管理员可以添加传说、史诗、稀有等新的等级。已经添加的等级可以进行排序调整,商家发布商品的时候可以选择新的等级。等级分类管理界面见图5-12。
图5-12等级分类管理界面
5.3.3 分类列表管理功能实现
管理员进入到分类列表管理模块,可以对整个平台所有的商品分类进行汇总。页面以树形结构展示游戏分类与等级分类的关联关系。管理员对商家提交的新分类申请进行审核,审核通过后分类生效。分类列表管理界面如下图5-13所示。
图5-13分类列表管理界面
5.3.4 店铺信息管理功能实现
管理员利用店铺信息管理模块对商家上传的商铺资料进行审核。页面展示待审核的店铺列表,点击店铺名称可以查看营业执照和联系方式等资质文件。管理员进行通过或者驳回操作,驳回时需要给出原因并告知商家。店铺信息管理界面如下图5-14所示。
图5-14店铺信息管理界面
5.3.5 游戏商城管理功能实现
管理员对游戏商城管理模块中所有平台的商品发布情况进行查看。页面上显示所有的商家所提交的全部商品,可以按照店铺名称或者商品状态进行筛选。管理员对违规商品进行下架处理,下架之后该商品在前端是看不到的。游戏商城管理界面如下图5-15所示。
图5-15游戏商城管理界面
5.3.6 订单售后管理功能实现
管理员在订单售后管理模块中对商家和用户不能达成一致意见的售后纠纷进行处理。页面展示申诉中售后记录,管理员对双方提交的凭证进行最后的判定。将判定结果同步到订单售后状态,通知用户。订单售后管理界面如下图5-16所示。
图5-16订单售后管理界面
第六章 系统测试
6.1 测试目的
系统测试主要是检验游戏武器模型销售平台是否达到了设计目的。通过执行测试用例来检验各个功能模块是否可以正常工作,保证普通用户、商家和管理员这三个角色的操作过程是完整的。测试过程中对系统在正常操作环境下响应的准确性进行考查,并且对异常输入时系统所具备的容错性以及错误提示是否合理进行考察。测试结果是系统交付的依据,也是后期维护、改进的参照。
6.2 测试方法
功能测试使用黑盒测试的方法,根据需求文档来设计测试用例以覆盖所有的功能点。测试人员用普通用户的模式进行商品浏览、加购、下单和评价的操作。商家端测试包括商品上架、订单处理和售后审核这三个流程。管理员后台测试有分类管理、店铺审核和纠纷仲裁三种[20]。单元测试与开发同步,在核心业务方法上写测试代码来检验逻辑是否正确。集成测试检验各个模块之间数据传递的连续性。
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店铺审核测试用例表
| 审核管理 | 待审核列表加载 | 进入审核页面 | 显示待审核店铺 | 列表加载正常 | 符合预期 |
| 审核管理 | 资质文件查看 | 点击店铺名称 | 显示资质图片 | 文件可正常查看 | 符合预期 |
| 审核管理 | 审核结果提交 | 选择通过或驳回 | 状态更新并通知 | 审核结果生效 | 符合预期 |
测试结论
系统功能测试包含普通用户、商家和管理员这三个主要的业务模块。测试用例有游戏商城浏览、购物车管理、订单提交、商品评论、商品上架、订单处理以及店铺审核共7个功能点。在执行测试的过程中各个功能都可以被正常的响应,没有因为页面的跳转或者数据的加载而产生卡顿或者错误的情况。商品信息从商城列表到详情页的传递是正确的,购物车数量改变时金额也会随之变化。订单提交阶段收货地址的选择同订单的产生保持一致,数据库中的记录和前端展示的状态也是一致的。用户发表评论之后,内容就会立刻显示在商品详情页的评论区里。商家发布商品的时候图片上传和信息保存功能正常,提交审核之后的状态变化正确。商家发货操作会把订单状态由待发货变为待签收。管理员审核店铺资料时可以查看商家提交的资质文件,并且可以通过或者驳回的方式进行处理,状态反馈也较为及时。经过测试得到的结果和预期结果一致,系统的各项功能运行情况较好。
总结
游戏武器模型属于数字娱乐消费的主要品类之一,它的交易一直分散在通用的电商平台以及玩家私下交流的方式上,存在着信息不对称状况、缺少交易监管机制和售后维权难等问题。本文根据以上问题提出一个专业的垂直交易平台,给玩家提供集中展示和在线交易的渠道,给商家提供规范的商品管理后台,并且设置平台审核制度保证交易的安全性。系统达到了设计预期的目标,很好地打通了从商品发布、交易到售后服务评价的全部业务流程。
研究工作按照软件工程规范有条理地进行。需求分析阶段整理出普通用户、商家和管理员的角色以及浏览、下单、审核店铺等功能。系统设计阶段使用B/S架构和前后端分离的方式,前端用Vue.js框架来创建交互界面,后端用Spring Boot来实现业务逻辑,并且把MySQL数据库用来保存数据。编码实现阶段完成三个角色的功能模块开发,普通用户可以进行商品购买和评论发表,商家可以对商品上下架、订单发货进行操作,管理员可以对分类信息及纠纷仲裁进行操作。测试阶段就主要业务模块编写测试用例,检验系统的正确性、稳定性能。
系统还存在着一些不足。支付功能使用模拟的方式实现,并没有接入真实的第三方支付接口,不能进行真正的资金流动。物流信息依靠商家手工录入,缺少同快递公司的系统直接对接,造成订单状态的更新迟缓。商品推荐机制采用简单的按时间顺序排序的方法,没有对用户的使用行为进行分析,个性化程度不高。服务器是用本地化的方式进行部署,由于硬件的因素造成并发的访问量受到限制。
后续研究可针对上述不足进行改进。接入真实的微信支付、支付宝等支付接口,使交易闭环更加完整。集成快递鸟等物流API服务,完成物流轨迹的自动查询和状态同步。采用基于用户浏览历史和购买记录的推荐算法来提高商品发现的准确性。系统上线之后可以给游戏玩家创建起安全可靠的数字商品交易环境,促使虚拟资产交易朝着规范化、平台化的方向前进,有着十分宽广的应用前景和社会价值。
参考文献
[1] 刘旭颖.情绪导向型虚拟商品交易呼唤有力规制[N].国际商报, 2025-12-08(005). DOI: 10.28270/n.cnki.ngjsb.2025.004920.
[2] 仝若楠. CS2道具暴跌!游戏虚拟装备还保值吗[N].三湘都市报, 2025-10-28(A07).
[3] 孔杨玉滢,葛明亮.不法分子盯上了“免押金0元租”游戏装备[J].方圆, 2025, (18): 56-57.
[4] 胡文滔.想要游戏体验好,这些外设装备不能少[N].电脑报, 2025-07-14(044). DOI: 10.28184/n.cnki.ndina.2025.000413.
[5] 唐超,付常青.游戏:管理者的新装备[J].中国医院院长, 2024, 20(24): 85.
[6] 李顾珵.一根金箍棒,撬动游戏装备消费市场[N].国际商报, 2024-08-26(005). DOI: 10.28270/n.cnki.ngjsb.2024.002501.
[7] 吴昊洋.网络游戏装备用户权利属性研究[D].长春:吉林大学, 2024. DOI: 10.27162/d.cnki.gjlin.2024.006606.
[8] Nian Z. The Application of Event Study Method in Virtual Goods Markets: Based on CS:GO Skin Prices[J]. Frontiers in Economics and Management, 2026, 7(1): 69-85. DOI: 10.6981/FEM.202601_7(1).0007.
[9] Vu V T, Nguyen H T Y, Nguyen V P. Predicting virtual goods purchases in Vietnam's MMOGs with a TAM-PERVAL model using PLS-SEM and ANN[J]. Humanities and Social Sciences Communications, 2026, 13(1): 80. DOI: 10.1057/S41599-025-06379-2.
[10] Bai K, Liu Y. Scarcity, symbolism, and social identity (3S): Unpacking drivers of conspicuous consumption of virtual gear in the metaverse[J]. Journal of Retailing and Consumer Services, 2025, 87: 104396. DOI: 10.1016/J.JRETCONSER.2025.104396.
[11] Nadjim M, Mahmut B, Yaser A, et al. Exploring virtual goods purchase intentions: an integrated SEM-NCA approach in online gaming[J]. Central European Management Journal, 2024, 32(3): 368-391. DOI: 10.1108/CEMJ-09-2023-0350.
[12] Fukuda R, Nomura T, Akamatsu N. Translating virtual product scarcity in gaming to real-world brand value[J]. Psychology & Marketing, 2024, 41(11): 2608-2624. DOI: 10.1002/MAR.22071.
[13] 约翰·卡内尔,伊拉里·华卢波·桑切斯. Spring微服务实战[M].北京:人民邮电出版社, 2022: 379.
[14] 黄菊华. Vue.js入门与商城开发实战[M].北京:机械工业出版社, 2022: 687.
[15] 邓文达,邓河. MySQL数据库运维与管理[M].北京:人民邮电出版社, 2023: 411.
[16] 朱书彪.中职《Java程序设计》项目课程开发与实践[D].桂林:广西师范大学, 2025: 1-120.
[17] 杨开振.深入浅出Spring Boot 3.x[M].北京:人民邮电出版社, 2024: 408.
[18] 胡劲.数据库信息管理系统的逻辑架构与功能设计探析[J].电脑知识与技术, 2023, 19(19): 96-98.
[19] 林育蓓,汤德佑,汤娜.数据库技术及应用[M].北京:机械工业出版社, 2024: 302.
[20] 付朝晖.软件测试技术与实践[M].北京:电子工业出版社, 2023: 217.
致 谢
时间过得很快,毕业来临。站在大学生活结束的时候回顾起来,从选题开始的迷茫到系统形成时的释然,这条路是靠师长和亲朋好友的帮助才走过来的。
衷心感谢校内的指导老师给予的帮助。老师治学严谨,在选题方向、开题报告、系统设计、论文撰写等各个阶段都给予了精心指导。当出现技术上的难题时,老师会给予耐心的指导来激发学生的思维,论文修改期间,对每一个细节都进行仔细的检查,并且给出宝贵的修改意见。同时也要感谢企业的导师给我的工程实践提供了很多的帮助,在我进行项目落地以及实际开发的规范方面也有所认识。
毕业设计是全方位的历练。从需求分析到系统实现每一个阶段都存在困难,将理论知识应用到技术问题解决的过程中加深了对专业知识的理解。大学四年将要结束,这一段时间里所形成起来的系统知识结构和确定的人生目标,都会在毕业后被进一步强化与升华。
感谢计算机学院各位老师对我的悉心教导,也感谢辅导员老师平时对我生活、学习上的关心和帮助,更感谢任课老师在我课堂内外的言传身教。衷心感谢同窗好友和实验室同伴们,在共同探讨问题、调试程序的时候给我们留下的最宝贵的回忆。你的陪伴使这段求学之旅不再孤独。
最后要感谢的则是父母、家庭。二十多年的养育之恩,你们就是我最坚强的后盾。无论顺境还是逆境,你给予我的支持与鼓励,使我能够全力以赴地投入到学习当中。走出校门走进社会之后,怀着一颗感恩的心前进,用学到的知识来报答父母和祖国。
点赞+收藏+关注 →私信领取本源代码、数据库
关注博主下篇更精彩
一键三连!!!
一键三连!!!
一键三连!!!
感谢一键三连!!!
网硕互联帮助中心![[玩转Spring]盘点 Spring 常用扩展点:BeanFactoryPostProcessor、BeanPostProcessor、@Enable、自动配置到底该用哪个?-网硕互联帮助中心](https://www.wsisp.com/helps/wp-content/uploads/2026/10/20261011164102-6acbbc1e47136-220x150.png)







评论前必须登录!
注册