docs: 添加论文参考文档和撰写规范
包含毕业设计论文撰写规范、萌贝母婴商城论文初稿、爱维宠物医院系统论文参考 Ultraworked with [Sisyphus](https://github.com/code-yeongyu/oh-my-opencode) Co-authored-by: Sisyphus <clio-agent@sisyphuslabs.ai>
This commit is contained in:
307
example/2026届网络工程毕业设计论文撰写规范-（应用开发类).md
Normal file
307
example/2026届网络工程毕业设计论文撰写规范-（应用开发类).md
Normal file
@@ -0,0 +1,307 @@
|
||||
# 2026届网络工程毕业设计
|
||||
|
||||
# 论文撰写规范（应用开发类）
|
||||
|
||||
中文摘要 (3-5 个关键词)
|
||||
|
||||
# 英文摘要
|
||||
|
||||
# 目录
|
||||
|
||||
# 第1章绪论
|
||||
|
||||
1.1 课题来源及意义
|
||||
|
||||
1.2 课题研究现状
|
||||
|
||||
1.3当前存在的问题
|
||||
|
||||
1.4 课题研究目标
|
||||
|
||||
# 第2章主要技术和框架
|
||||
|
||||
2.1 主要技术 (开发系统或平台所需相关技术的介绍)
|
||||
|
||||
# 2.2 框架和开发模式（开发系统或平台所使用的框架和开发模式的介绍）
|
||||
|
||||
# 第3章XXXXX的系统分析
|
||||
|
||||
# 3.1需求分析（包括功能需求分析和性能需求分析）
|
||||
|
||||
3.2可行性分析（包括技术可行性、操作可行性、经济可行性，社会可行性等）
|
||||
|
||||
3.3 用例图（根据系统角色划分用例图，若有两个角色就有两个用例图）
|
||||
|
||||
3.3.1 用户用例图（需先对用例图进行描述，其实也就是对该系统的用户角色进行权限分析，再画出具体用户用例图，用例图如下所示）
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
图3.1用户用例图
|
||||
|
||||
|
||||
3.3.2 管理员用例图（需先对用例图进行描述，其实也就是对该系统的用户角色进行权限分析，再画出具体用户用例图，用例图如下所示）
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
图3.2管理员用例图
|
||||
|
||||
|
||||
3.4 用例描述（用例描述是对用例图中用例的详细说明，它详细阐述了用例的功
|
||||
|
||||
能实现过程、输入输出、前置条件、后置条件以及可能的异常情况等，是对用例图
|
||||
|
||||
的补充和细化，使系统功能更加清晰具体。需分别对每个用例列举3个左右的用
|
||||
|
||||
例描述。）
|
||||
|
||||
例：（1）用户管理地址用例描述如下表3.1所示。
|
||||
|
||||
|
||||
表 3.1 用户管理地址用例描述
|
||||
|
||||
|
||||
<table><tr><td>用例名称：管理地址</td></tr><tr><td>执行者：用户</td></tr><tr><td>简要说明：用户对收货地址进行添加、修改、删除等管理操作</td></tr><tr><td>基本事件流：
|
||||
1.用户登录平台，进入地址管理界面
|
||||
2.系统显示已有地址列表
|
||||
3.用户选择添加新地址，输入详细地址信息，验证通过后存储地址
|
||||
4.若修改地址，系统更新后提示成功，若删除地址，确认操作后数据库移除该地址记录</td></tr><tr><td>(2)用户查看商品用例描述如下表3.2所示。
|
||||
表3.2用户查看商品用例</td></tr><tr><td>用例名称：查看商品</td></tr><tr><td>执行者：用户</td></tr><tr><td>简要说明：用户分类浏览平台上的闲置商品</td></tr><tr><td>基本事件流：
|
||||
1.用户登录平台，进入查看商品界面
|
||||
2.选择商品分类，如闲置书籍、衣服、手机等；
|
||||
3.系统加载并显示该分类下的商品列表
|
||||
4.用户可点击具体商品，查看详细信息，如介绍、图片、价格等</td></tr></table>
|
||||
|
||||
# 3.5 系统性能分析
|
||||
|
||||
# 第4章XXXXX的系统设计
|
||||
|
||||
4.1系统功能设计(先总体概述一段该系统的主要角色有哪几个，分别包含什么主
|
||||
|
||||
要功能，再给出功能结构图。)
|
||||
|
||||
具体如图4.1和图4.2所示。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
图4.1用户功能结构图
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
图4.2管理员功能结构图
|
||||
|
||||
|
||||
4.2 类图（根据给定的初步类图，详细描述每个类的属性、方法以及类之间的具体关系。）
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
图4.3系统类图
|
||||
|
||||
|
||||
4.3 序列图（展示了对象之间随时间顺序发生的消息传递，通常用于描述用例的实现过程或系统中某个功能的动态行为。至少需列举系统角色各一个序列图，在给出序列图之前还需将过程的详细步骤写出。如：用户登录序列图、管理员删除账号序列图。）
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
图4.4用户购买商品功能序列图
|
||||
|
||||
|
||||
4.4 活动图（活动图可以清晰地描述系统的动态行为和工作流程。例如，在描述一个在线购物系统的订单处理流程时，可以通过活动图展示从用户下单到订单完成的各个步骤。论文中至少需描述各个角色各一个活动的活动图，如用户更新个人信息活动图，管理员删除用户信息活动图。）
|
||||
|
||||
# 4.4.1 用户填写个人信息活动图
|
||||
|
||||
用户填写个人信息过程可分为以下几步：
|
||||
|
||||
(1) 用户输入验证账号密码。
|
||||
|
||||
(2) 数据库查询用户数据，并判断用户是否存在。
|
||||
|
||||
(3) 登录成功后，用户填写个人信息并提交。
|
||||
|
||||
(4) 系统接收提交的个人信息后，将其发送至数据库进行更新保存。
|
||||
|
||||
(5) 用户确认信息更新无误后，更新界面。
|
||||
|
||||
用户填写个人信息活动图如下图4.7所示。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
图4.7 用户填写个人信息活动图
|
||||
|
||||
|
||||
# 4.5 数据库设计
|
||||
|
||||
撰写说明：
|
||||
|
||||
本章是重点章节，很多同学搞不清概念设计、逻辑设计和物理设计的关系，请参见另外一个文档《2026届网络工程毕业论文第4章-数据库设计撰写规范（应用开发类补充说明）.docx》：
|
||||
|
||||
4.5.1 概念设计（概念设计包括两部分：实体属性图（不少于8个实体，每个实体
|
||||
|
||||
标明属性图的主码）和总体E-R图）
|
||||
|
||||
# (1) 管理员实体
|
||||
|
||||
管理员实体属性图如图4.9所示。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
图4.9管理员实体属性图
|
||||
|
||||
|
||||
# (2）用户实体
|
||||
|
||||
用户实体属性图如图4.10所示。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
图4.10用户实体属性图
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
图4.系统E-R图（标明各个实体之间的关联）
|
||||
|
||||
|
||||
4.5.2 逻辑设计（将E-R图中的实体关系转换为逻辑结构设计，即关系模式。
|
||||
|
||||
其中，一个实体转换为 1 个单独的关系模式。
|
||||
|
||||
实体间联系有3种，1:1，1:n，n:m。
|
||||
|
||||
1:n 联系要将 1 端实体如用户的主码加入到 n 端如评论实体的关系模式中。
|
||||
|
||||
n:m 联系要将联系如上图中的购买转换成一个单独的关系模式,并将两端的主
|
||||
|
||||
码放入该关系模式作为属性。）关系模式中需标明主外码
|
||||
|
||||
上图转换为逻辑结构如下所示：
|
||||
|
||||
(1) 用户表：(用户 id, 用户账号, 密码, 用户姓名, 性别, 联系电话, 头像, 积分，余额)
|
||||
|
||||
(2) 管理员表: (管理员 id, 创建时间, 管理员名称, 密码, 管理员类型)
|
||||
|
||||
(3) 收货地址表：（收货地址id，用户id，地址，收货人，电话，是否为默认地址）
|
||||
|
||||
(4) 购物车表：（购物车id，商品表名，商品，商品名称，图片，购买数量，单价，会员价，商品类型）
|
||||
|
||||
(5) 订单表：（订单id，订单编号，用户id，规格，上架时间，商品详情，团购价，拼团人数）
|
||||
|
||||
(6) 团购商品表：（团购商品id，购买数量，价格，折扣价，总价，商品类型id，支付类型，物流，购物车id）
|
||||
|
||||
(7) 商品类型表：（商品类型 id，创建时间，类型数量）
|
||||
|
||||
(8) 评论表：（评论id，用户id，头像，用户名，评论内容，回复内容）
|
||||
|
||||
(9) 公告表：（公告id，创建时间，标题，简介，图片，内容，管理员id）
|
||||
|
||||
(10) 购买表：（用户 id，团购商品 id，购买日期，购买时间）（购买表的外键为：
|
||||
|
||||
用户id，团购商品id)
|
||||
|
||||
4.5.3 物理设计（将上述关系模式转换为一个个物理表结构，一个关系模式转换为一个物理表，至少包含8张物理表）
|
||||
|
||||
如：（1）系统根据MySQL数据库数据存储的特性设计数据库关系表：
|
||||
|
||||
|
||||
表 4.1 管理员表 (admin 表)
|
||||
|
||||
|
||||
<table><tr><td>字段名称</td><td>字段意义</td><td>数据类型</td><td>长度</td><td>完整性约束</td></tr><tr><td>admin_id</td><td>管理员 id</td><td>int</td><td>10</td><td>主键</td></tr><tr><td>admin_name</td><td>管理员姓名</td><td>varchar</td><td>10</td><td>非空</td></tr><tr><td>admin_password</td><td>管理员密码</td><td>varchar</td><td>20</td><td>非空</td></tr><tr><td>admin_email</td><td>管理员邮箱</td><td>varchar</td><td>20</td><td>非空</td></tr><tr><td>admin_phone</td><td>管理员手机号</td><td>varchar</td><td>11</td><td>非空</td></tr></table>
|
||||
|
||||
|
||||
表 4.2 用户表 (user 表)
|
||||
|
||||
|
||||
<table><tr><td>字段名称</td><td>字段意义</td><td>数据类型</td><td>长度</td><td>完整性约束</td></tr><tr><td>user_id</td><td>用户id</td><td>int</td><td>10</td><td>主键</td></tr><tr><td>user_name</td><td>用户昵称</td><td>varchar</td><td>10</td><td>非空</td></tr><tr><td>user_password</td><td>用户密码</td><td>varchar</td><td>20</td><td>非空</td></tr><tr><td>user/mobile</td><td>用户电话</td><td>varchar</td><td>11</td><td>非空</td></tr><tr><td>user_realname</td><td>用户真实姓名</td><td>varchar</td><td>10</td><td>非空</td></tr><tr><td>user_score</td><td>信誉分</td><td>int</td><td>4</td><td>非空</td></tr></table>
|
||||
|
||||
|
||||
表4.3商品表 (product表)
|
||||
|
||||
|
||||
<table><tr><td>字段名称</td><td>字段意义</td><td>数据类型</td><td>长度</td><td>完整性约束</td></tr><tr><td>product_id</td><td>商品id</td><td>int</td><td>10</td><td>主键</td></tr><tr><td>product_name</td><td>商品名称</td><td>varchar</td><td>10</td><td>非空</td></tr><tr><td>product_title</td><td>商品概要</td><td>varchar</td><td>50</td><td>非空</td></tr><tr><td>product_intro</td><td>商品详情</td><td>varchar</td><td>100</td><td>非空</td></tr></table>
|
||||
|
||||
4.6图形界面设计（实现某一个具体功能的界面设计，至少系统中各角色各列举1
|
||||
|
||||
# 个功能界面设计)
|
||||
|
||||
如：删除购物车界面设计
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
图4. 删除购物车界面设计图
|
||||
|
||||
|
||||
# 第5章XXXXX的系统实现
|
||||
|
||||
只写出主要功能的实现结果即可，并给出运行截图（不写用户注册、登录），
|
||||
|
||||
运行截图中需输入数据的地方要有数据输入，且输入的数据必须真实，不可输入
|
||||
|
||||
类似 1111 类数据。可按系统角色进行实现，再进行角色详细功能实现。如：
|
||||
|
||||
# 5.1 用户功能模块
|
||||
|
||||
# 5.1.1 购物车
|
||||
|
||||
# 5.1.2 我的订单
|
||||
|
||||
··
|
||||
|
||||
# 5.2 管理员功能模块
|
||||
|
||||
# 5.2.1 账号管理
|
||||
|
||||
# 5.2.2 订单管理
|
||||
|
||||
··
|
||||
|
||||
# 第6章XXXXX的系统测试
|
||||
|
||||
# 6.1 系统测试概述
|
||||
|
||||
6.1.1 测试的背景
|
||||
|
||||
6.1.2 测试的意义
|
||||
|
||||
6.1.3 测试的环境
|
||||
|
||||
# 6.2 系统测试用例设计
|
||||
|
||||
6.2.1XXXX功能测试
|
||||
|
||||
6.2.2XXXX功能测试
|
||||
|
||||
6.2.3XXXX功能测试
|
||||
|
||||
6.2.4 安全性测试
|
||||
|
||||
6.2.5 兼容性测试
|
||||
|
||||
# 第7章结论
|
||||
|
||||
参考文献
|
||||
|
||||
致谢
|
||||
|
||||
附录
|
||||
1063
example/爱维宠物医院管理系统毕业论文-2026版.md
Normal file
1063
example/爱维宠物医院管理系统毕业论文-2026版.md
Normal file
File diff suppressed because it is too large
Load Diff
759
example/萌贝母婴商城毕业论文初稿-2026版.md
Normal file
759
example/萌贝母婴商城毕业论文初稿-2026版.md
Normal file
@@ -0,0 +1,759 @@
|
||||
# 萌贝母婴商城系统的设计与实现（论文初稿）
|
||||
|
||||
## 中文摘要
|
||||
|
||||
随着我国生育政策持续优化、年轻家庭消费升级以及移动互联网基础设施的不断完善，母婴电商正在从“流量驱动”向“服务驱动”和“信任驱动”转变。传统母婴用品销售方式在商品信息透明度、跨地区供给效率、售后协同与数据化经营方面存在明显短板，难以满足用户在安全性、时效性、体验一致性等方面的综合需求。针对上述问题，本文围绕“萌贝母婴商城系统”开展了从需求分析、架构设计、数据库建模、功能实现到测试验证的系统化研究与实践。
|
||||
|
||||
本系统采用前后端分离架构，后端以 Spring Boot 3、Spring Data JPA、MySQL 为核心技术，前端基于 Vue3、Vite 与 Arco Design 构建多角色交互界面，形成顾客端、商家端、管理员端三端协同的业务平台。在功能层面，系统实现了用户注册登录、商品浏览与检索、购物车管理、下单与订单管理、收藏与评价、商家商品管理、发货与退款处理、平台审核与用户管理、轮播图配置、库存记录与物流查看等核心能力；在工程层面，系统通过统一接口响应模型、基于 Token 的鉴权机制、角色访问约束和异常处理机制保障了业务一致性与运行稳定性。
|
||||
|
||||
通过对关键业务链路进行功能测试与流程验证，结果表明该系统能够较好支持中小规模母婴电商场景下的日常运营，提升顾客购买效率、商家运营效率与平台监管效率。本文研究成果可为同类垂直电商系统建设提供参考，并为后续引入推荐算法、支付风控和精细化运营分析提供可扩展基础。
|
||||
|
||||
**关键词：** 母婴电商；Spring Boot；Vue3；前后端分离；角色权限控制
|
||||
|
||||
## Abstract
|
||||
|
||||
With the continuous optimization of childbirth policies in China, the upgrading of family consumption, and the rapid development of mobile Internet infrastructure, maternal and infant e-commerce is shifting from traffic-driven growth to service-driven and trust-driven development. Traditional sales models for maternal and infant products still suffer from low transparency of product information, limited cross-regional supply efficiency, weak after-sales collaboration, and insufficient data-driven operations, which can hardly satisfy users' comprehensive requirements on safety, timeliness, and consistent service experience. To address these issues, this thesis conducts a systematic study and implementation of the “Mengbei Maternal Mall System”, covering requirement analysis, architecture design, database modeling, functional implementation, and testing verification.
|
||||
|
||||
The system adopts a frontend-backend separated architecture. The backend is built on Spring Boot 3, Spring Data JPA, and MySQL, while the frontend is developed with Vue3, Vite, and Arco Design. It supports collaborative operations across three roles: customer, merchant, and administrator. Functionally, the system implements user registration and login, product browsing and search, shopping cart management, order placement and order lifecycle management, favorites and reviews, merchant product operations, shipment and refund handling, platform audit and user management, banner configuration, inventory records, and logistics tracking. At the engineering level, the system ensures consistency and stability through a unified API response model, token-based authentication mechanism, role-based access control, and centralized exception handling.
|
||||
|
||||
Functional testing and process verification show that the system can effectively support daily operations in small and medium-sized maternal e-commerce scenarios, improving shopping efficiency for customers, operational efficiency for merchants, and governance efficiency for platform administrators. The outcomes of this study can provide practical references for similar vertical e-commerce systems and establish an extensible foundation for future integration of recommendation algorithms, payment risk control, and refined operational analytics.
|
||||
|
||||
**Keywords:** Maternal e-commerce; Spring Boot; Vue3; Frontend-backend separation; Role-based access control
|
||||
|
||||
## 目录
|
||||
|
||||
- 第1章 绪论
|
||||
- 1.1 课题来源及意义
|
||||
- 1.2 国内外研究现状
|
||||
- 1.3 当前存在的问题
|
||||
- 1.4 研究目标与内容
|
||||
- 1.5 论文结构安排
|
||||
- 第2章 相关技术与开发框架
|
||||
- 2.1 后端技术体系
|
||||
- 2.2 前端技术体系
|
||||
- 2.3 鉴权与访问控制机制
|
||||
- 2.4 技术选型对比与决策依据
|
||||
- 第3章 萌贝母婴商城系统分析
|
||||
- 3.1 需求分析
|
||||
- 3.2 可行性分析
|
||||
- 3.3 角色用例分析
|
||||
- 3.4 关键用例描述
|
||||
- 3.5 非功能需求分析
|
||||
- 第4章 萌贝母婴商城系统设计
|
||||
- 4.1 系统总体架构设计
|
||||
- 4.2 功能结构设计
|
||||
- 4.3 数据库设计
|
||||
- 4.4 接口与权限设计
|
||||
- 4.5 关键流程设计
|
||||
- 4.6 界面设计
|
||||
- 第5章 萌贝母婴商城系统实现
|
||||
- 5.1 用户认证与基础模块实现
|
||||
- 5.2 顾客端功能实现
|
||||
- 5.3 商家端功能实现
|
||||
- 5.4 管理员端功能实现
|
||||
- 5.5 关键业务链路实现结果
|
||||
- 第6章 萌贝母婴商城系统测试
|
||||
- 6.1 测试环境与测试策略
|
||||
- 6.2 功能测试
|
||||
- 6.3 安全性与兼容性测试
|
||||
- 6.4 测试结果分析
|
||||
- 第7章 结论与展望
|
||||
- 参考文献
|
||||
- 致谢
|
||||
- 附录
|
||||
|
||||
---
|
||||
|
||||
## 第1章 绪论
|
||||
|
||||
### 1.1 课题来源及意义
|
||||
|
||||
近年来，母婴消费行业呈现出需求精细化、渠道线上化和服务链路一体化的趋势。用户在选择母婴用品时，不再仅关注价格和促销，更重视产品质量、品牌信誉、成分安全、物流时效以及售后保障。与此同时，大量中小型商家虽具备优质供应能力，但在数字化运营、跨区域触达和平台治理方面能力不足，导致“好产品触达难、好服务沉淀难、好口碑传播难”的结构性问题长期存在。
|
||||
|
||||
本课题来源于母婴垂直电商业务实践需求，目标是设计并实现一套可落地、可扩展、可维护的三端协同商城系统。该系统以顾客、商家、管理员三类角色为中心，围绕“商品展示—交易下单—订单履约—售后处理—平台治理”的主业务链路展开，既要解决顾客侧购物与服务体验问题，也要兼顾商家侧运营效率与平台侧风控监管需求。
|
||||
|
||||
从现实意义看，本研究有助于推动中小型母婴业务主体完成数字化转型，降低运营成本，提高交易透明度与服务响应能力。从技术意义看，本研究可验证前后端分离架构在中等复杂业务场景中的适配性，形成可复用的系统建设方法论。从教学与实践意义看，本文在分析、设计、实现和测试四个环节形成闭环，有助于提升软件工程项目化实践能力。
|
||||
|
||||
### 1.2 国内外研究现状
|
||||
|
||||
国外电商平台在用户行为分析、供应链协同、支付风控、推荐系统等方面起步较早，系统形态相对成熟。Amazon、Walmart、Target 等平台在订单履约、库存联动和个性化推荐方面形成了完整方法体系；在母婴垂直领域，平台通常通过类目化管理、质量追溯和会员体系提升用户粘性。近年来，国外研究重点从“交易系统可用性”逐步转向“算法驱动增长”和“合规治理”，尤其重视隐私保护、交易安全与平台透明度。
|
||||
|
||||
国内母婴电商经过快速发展，已形成综合电商平台母婴频道与垂直母婴平台并行的格局。大量研究围绕 B/S 架构电商系统、Spring Boot + Vue 组合、订单与库存管理、权限控制等主题展开。现有成果在基础交易流程方面较完善，但在多角色协同、审核流程规范化、平台治理可视化以及运营数据沉淀方面仍有较大提升空间。
|
||||
|
||||
从已有文献和开源项目观察，当前典型问题包括：其一，系统功能多停留在“增删改查”层面，缺少完整业务闭环与跨模块联动；其二，部分系统权限边界不清晰，存在越权风险；其三，文档与实现脱节，导致论文陈述与系统实际不一致。基于此，构建一套与真实代码实现严格对齐、并具有工程可复现性的母婴商城系统，具有明确研究价值。
|
||||
|
||||
### 1.3 当前存在的问题
|
||||
|
||||
通过需求调研和项目分析，可归纳出母婴交易场景中的主要问题如下：
|
||||
|
||||
1. **顾客侧体验不连贯。** 商品检索、收藏、加购、下单、查看物流、申请退款等行为分散，若系统设计不统一，用户需要多次跳转，交互成本较高。
|
||||
2. **商家侧运营工具不足。** 商家若无法及时查看订单、处理发货、核对库存变更与评价反馈，容易造成履约延迟与售后争议。
|
||||
3. **平台侧治理能力薄弱。** 缺少审核、风险订单识别、用户状态管理等能力时，平台难以有效维护交易秩序。
|
||||
4. **数据链路不完整。** 若订单、订单明细、物流、库存记录之间关联不清晰，无法支撑后续对账、统计分析和运营优化。
|
||||
5. **权限与认证机制不统一。** 如果没有统一鉴权机制和角色约束，系统将面临安全与一致性风险。
|
||||
|
||||
### 1.4 研究目标与内容
|
||||
|
||||
本文研究目标是实现一套覆盖顾客端、商家端、管理员端的母婴商城系统，并在论文层面形成“需求—设计—实现—测试”完整论证链条。具体目标包括：
|
||||
|
||||
- 建立清晰的多角色业务边界和访问权限体系；
|
||||
- 打通商品浏览、购物车、订单、物流、库存、审核等核心业务流程；
|
||||
- 构建结构化数据库模型，保障关键业务对象的可追踪性；
|
||||
- 形成可验证的测试方案，证明系统在功能与稳定性方面满足预期；
|
||||
- 提供可扩展基础，支持后续接入智能推荐、风控与运营分析。
|
||||
|
||||
围绕上述目标，本文重点研究内容包括：需求建模、体系架构设计、数据库设计、接口设计、关键模块实现、测试验证与结果分析。
|
||||
|
||||
### 1.5 论文结构安排
|
||||
|
||||
全文共分七章。第1章介绍研究背景、问题、目标与论文结构；第2章阐述系统实现所需的技术与框架；第3章完成系统需求、可行性与用例分析；第4章进行系统架构、数据库、接口和流程设计；第5章说明系统实现过程与关键模块结果；第6章给出测试策略、测试用例与结果分析；第7章总结研究成果并提出未来改进方向。
|
||||
|
||||
---
|
||||
|
||||
## 第2章 相关技术与开发框架
|
||||
|
||||
### 2.1 后端技术体系
|
||||
|
||||
#### 2.1.1 Spring Boot 3
|
||||
|
||||
Spring Boot 3 提供约定优于配置的开发模式，能够快速构建独立运行的企业级 Web 应用。其自动配置机制简化了项目初始化与组件整合过程，使开发者能够将主要精力聚焦于业务逻辑实现。对于本系统而言，Spring Boot 主要承担 REST 接口发布、依赖注入、生命周期管理、异常处理统一化等职责。
|
||||
|
||||
在工程实现中，系统通过控制器层接收请求、服务层处理业务、仓储层访问数据库，形成分层清晰的后端结构。该模式降低了模块耦合度，提升了维护效率和可测试性。
|
||||
|
||||
#### 2.1.2 Spring Data JPA
|
||||
|
||||
Spring Data JPA 为数据访问层提供了较高抽象，开发者可通过 Repository 接口快速完成常见持久化操作。相比手写大量 SQL 或样板代码，该技术在中型项目中能够显著提升开发效率。系统中用户、商品、订单、订单明细、物流、库存记录等对象均通过实体映射与仓储接口完成数据读写。
|
||||
|
||||
#### 2.1.3 MySQL 8
|
||||
|
||||
MySQL 8 作为关系型数据库，具有成熟稳定、生态完善和部署成本可控的优势，适合本课题中结构化业务数据的持久化存储。系统基于主键、自增、唯一约束等机制保证数据一致性，并通过业务字段（状态、创建时间、更新时间）支撑订单生命周期管理和审计追踪。
|
||||
|
||||
### 2.2 前端技术体系
|
||||
|
||||
#### 2.2.1 Vue3 与 Vite
|
||||
|
||||
Vue3 采用组件化开发思想，结合响应式机制可高效构建中大型单页应用。Vite 在开发期提供快速热更新能力，在构建期具备较高效率，适合毕业设计项目的迭代开发需求。系统前端将管理员、商家和顾客页面进行模块化拆分，通过统一组件风格和交互逻辑提升可维护性。
|
||||
|
||||
#### 2.2.2 Vue Router
|
||||
|
||||
Vue Router 负责路由组织与页面跳转。系统路由结构以角色分区为核心，管理员与商家采用 Layout + 子路由嵌套方式，顾客端以商品、购物车、订单、个人中心为主路径，保证了信息架构清晰和业务导航可理解。
|
||||
|
||||
#### 2.2.3 Arco Design
|
||||
|
||||
Arco Design 为后台管理与业务型界面提供了较丰富的组件库支持，如表格、表单、卡片、弹窗、标签等。通过统一视觉与交互规范，系统减少了重复样式开发成本，使团队可以将更多精力投入业务功能实现。
|
||||
|
||||
### 2.3 鉴权与访问控制机制
|
||||
|
||||
系统采用基于 Token 的鉴权模式。用户登录成功后，服务端生成唯一 Token 并保存至用户记录，前端在后续请求中通过 `X-Token` 请求头携带该凭证。后端拦截器在请求到达控制器前完成 Token 校验、用户状态校验和上下文注入，从而实现统一认证。
|
||||
|
||||
在授权方面，系统以角色为核心控制粒度，定义了 `ADMIN`、`MERCHANT`、`CUSTOMER` 三类角色。商家和管理员接口在进入业务逻辑前进行角色检查，确保访问边界清晰。该设计虽然较 JWT 方案更轻量，但在单体架构与中小并发场景下能够满足可用性与开发成本之间的平衡。
|
||||
|
||||
### 2.4 技术选型对比与决策依据
|
||||
|
||||
在后端框架选型中，Node.js、Django、Spring Boot 均可实现电商业务。综合考虑 Java 生态成熟度、工程化能力、团队技术基础与后续可扩展性，最终选择 Spring Boot 作为核心后端框架。数据访问层选择 JPA 以减少样板代码；数据库采用 MySQL 以获得部署便利和社区支持。
|
||||
|
||||
在前端选型中，React、Vue、Angular 均具备构建能力。考虑到学习曲线、项目周期、组件生态和开发效率，选择 Vue3 + Vite + Arco Design 的技术组合。该方案能够较快完成三端页面搭建并保持较好维护性。
|
||||
|
||||
综上，本系统技术路线遵循“实现目标明确、开发效率优先、稳定性可保障、后续扩展可承接”的原则，具有可行性与实践价值。
|
||||
|
||||
---
|
||||
|
||||
## 第3章 萌贝母婴商城系统分析
|
||||
|
||||
### 3.1 需求分析
|
||||
|
||||
#### 3.1.1 功能需求分析
|
||||
|
||||
系统功能从角色维度可分为顾客端、商家端、管理员端三个部分。
|
||||
|
||||
**（1）顾客端需求**
|
||||
|
||||
顾客是平台交易链路的核心参与者，主要功能需求如下：
|
||||
|
||||
- 用户注册与登录；
|
||||
- 商品浏览、分类筛选与关键字搜索；
|
||||
- 商品加入购物车、修改数量、移除；
|
||||
- 直接购买与购物车结算；
|
||||
- 收藏商品与取消收藏；
|
||||
- 查看订单、修改收货地址、申请退款、查看物流；
|
||||
- 对已购买商品进行评价；
|
||||
- 维护个人信息。
|
||||
|
||||
**（2）商家端需求**
|
||||
|
||||
商家是商品供给与履约主体，主要功能需求如下：
|
||||
|
||||
- 查看经营概览（订单量、销售额、热门商品等）；
|
||||
- 商品管理（新增、编辑、下架/删除）；
|
||||
- 订单管理（查看订单、执行发货、处理退款）；
|
||||
- 查看评价和物流记录；
|
||||
- 查看库存变更记录并进行必要清理；
|
||||
- 维护个人信息。
|
||||
|
||||
**（3）管理员端需求**
|
||||
|
||||
管理员承担平台治理职责，主要功能需求如下：
|
||||
|
||||
- 平台概览查看；
|
||||
- 订单管理与风险订单识别；
|
||||
- 退款审核、发货审核；
|
||||
- 商家入驻申请审核；
|
||||
- 用户管理（新增、修改、删除）；
|
||||
- 商品管理与审核；
|
||||
- 轮播图管理；
|
||||
- 查看评价、物流、库存数据。
|
||||
|
||||
#### 3.1.2 业务流程需求分析
|
||||
|
||||
系统主要业务流程如下：
|
||||
|
||||
1. 顾客登录后浏览商品并加入购物车；
|
||||
2. 顾客提交订单后，系统生成订单主记录与订单明细；
|
||||
3. 商家查看订单并执行发货；
|
||||
4. 顾客在订单生命周期内可查看物流、申请退款或修改地址（满足状态约束时）；
|
||||
5. 管理员对关键环节进行审核和监控；
|
||||
6. 库存记录与物流记录在业务动作中同步沉淀。
|
||||
|
||||
该流程强调“交易与治理并重”，兼顾用户体验和平台秩序。
|
||||
|
||||
### 3.2 可行性分析
|
||||
|
||||
#### 3.2.1 技术可行性
|
||||
|
||||
系统采用的技术栈均为成熟开源方案，社区文档丰富、工程案例充足。Spring Boot 与 Vue3 的组合在中小型 Web 应用中具有广泛实践，能够稳定支撑本项目的三端业务功能。MySQL 对于订单、商品等结构化数据管理具备良好适配性。综合评估后，技术风险可控。
|
||||
|
||||
#### 3.2.2 经济可行性
|
||||
|
||||
本系统主要依赖开源技术，无商业授权成本，开发与部署对硬件资源要求适中。对于中小团队或教学场景而言，整体投入较低，具备较高性价比。系统上线后可减少人工管理与沟通成本，长期收益明显。
|
||||
|
||||
#### 3.2.3 操作可行性
|
||||
|
||||
前端界面采用统一风格，操作路径清晰，用户学习门槛较低。管理员与商家端采用后台布局方式，便于快速定位功能入口。顾客端以购物流程为导向，减少复杂操作。整体上系统符合用户习惯，具备良好的可用性。
|
||||
|
||||
### 3.3 角色用例分析
|
||||
|
||||
#### 3.3.1 顾客用例
|
||||
|
||||
顾客用例包含：注册登录、浏览商品、搜索商品、加入购物车、立即购买、提交订单、查看订单、申请退款、查看物流、收藏商品、商品评价、修改个人信息等。
|
||||
|
||||
**图3.1 顾客用例图（论文定稿阶段插入）**
|
||||
|
||||
#### 3.3.2 商家用例
|
||||
|
||||
商家用例包含：登录、查看概览、商品管理、订单管理、发货处理、退款处理、评价查看、物流查看、库存记录查看、个人信息维护。
|
||||
|
||||
**图3.2 商家用例图（论文定稿阶段插入）**
|
||||
|
||||
#### 3.3.3 管理员用例
|
||||
|
||||
管理员用例包含：登录、平台概览、订单管理、风险订单查看、退款审核、发货审核、商家申请审核、用户管理、商品审核、轮播图管理、评价/物流/库存查看。
|
||||
|
||||
**图3.3 管理员用例图（论文定稿阶段插入）**
|
||||
|
||||
### 3.4 关键用例描述
|
||||
|
||||
#### 3.4.1 顾客下单用例描述
|
||||
|
||||
| 项目 | 内容 |
|
||||
|---|---|
|
||||
| 用例名称 | 顾客下单 |
|
||||
| 执行者 | 顾客 |
|
||||
| 前置条件 | 顾客已登录，购物车存在有效商品 |
|
||||
| 后置条件 | 生成订单与订单明细，购物车对应商品清空 |
|
||||
| 基本事件流 | 进入购物车→确认商品数量与地址→提交订单→系统校验库存→生成订单→返回成功结果 |
|
||||
| 异常事件流 | 商品库存不足或商品失效时，系统阻止下单并提示原因 |
|
||||
|
||||
#### 3.4.2 商家发货用例描述
|
||||
|
||||
| 项目 | 内容 |
|
||||
|---|---|
|
||||
| 用例名称 | 商家发货 |
|
||||
| 执行者 | 商家 |
|
||||
| 前置条件 | 商家已登录，订单属于当前商家且状态可发货 |
|
||||
| 后置条件 | 订单状态更新为已发货，新增物流记录 |
|
||||
| 基本事件流 | 进入订单管理→选择订单→填写发货备注→提交发货→系统更新订单状态和物流信息 |
|
||||
| 异常事件流 | 订单不属于当前商家或状态不允许发货时，系统拒绝操作 |
|
||||
|
||||
#### 3.4.3 管理员审核退款用例描述
|
||||
|
||||
| 项目 | 内容 |
|
||||
|---|---|
|
||||
| 用例名称 | 管理员审核退款 |
|
||||
| 执行者 | 管理员 |
|
||||
| 前置条件 | 管理员已登录，订单存在退款申请 |
|
||||
| 后置条件 | 订单退款状态更新并记录审核备注 |
|
||||
| 基本事件流 | 进入订单审核→查看退款原因→选择通过/驳回→提交审核→系统更新状态 |
|
||||
| 异常事件流 | 订单状态不匹配或参数非法时，系统返回错误提示 |
|
||||
|
||||
#### 3.4.4 管理员审核商家入驻用例描述
|
||||
|
||||
| 项目 | 内容 |
|
||||
|---|---|
|
||||
| 用例名称 | 商家入驻审核 |
|
||||
| 执行者 | 管理员 |
|
||||
| 前置条件 | 管理员已登录，存在待审核申请 |
|
||||
| 后置条件 | 申请状态更新为通过或驳回 |
|
||||
| 基本事件流 | 进入申请列表→查看资质信息→填写审核意见→提交结果 |
|
||||
| 异常事件流 | 申请不存在或状态已变更时，系统提示刷新后重试 |
|
||||
|
||||
### 3.5 非功能需求分析
|
||||
|
||||
#### 3.5.1 性能需求
|
||||
|
||||
系统应保证常见业务请求具备可接受响应速度，尤其是商品列表、订单列表、后台管理列表等高频查询场景。通过分页展示、条件过滤和必要索引设计，控制查询压力，避免前端一次性加载过多数据。
|
||||
|
||||
#### 3.5.2 安全需求
|
||||
|
||||
系统需具备统一认证机制与角色访问边界。未认证请求不得访问受限接口；不同角色仅可访问授权资源。关键业务应进行参数校验与状态校验，降低越权操作和非法输入风险。
|
||||
|
||||
#### 3.5.3 可维护性需求
|
||||
|
||||
系统模块应具备清晰边界，接口命名与响应结构保持统一，异常处理集中化。代码层面采用分层架构，文档层面保证“描述与实现一致”，便于后续迭代。
|
||||
|
||||
#### 3.5.4 可扩展性需求
|
||||
|
||||
系统应预留推荐、支付、营销活动、消息通知、报表分析等扩展接口。新增业务应在现有数据模型上以增量方式演进，避免大规模重构核心链路。
|
||||
|
||||
---
|
||||
|
||||
## 第4章 萌贝母婴商城系统设计
|
||||
|
||||
### 4.1 系统总体架构设计
|
||||
|
||||
系统采用典型的前后端分离架构。前端负责交互展示与状态管理，通过 HTTP 请求调用后端 API；后端负责业务逻辑处理、权限校验和数据持久化；数据库负责核心业务数据存储。
|
||||
|
||||
在部署结构上，前端可通过静态资源服务对外提供页面访问，后端作为独立服务提供 REST 接口，MySQL 提供统一数据存储。该架构具备解耦性强、职责清晰、便于扩展的特点。
|
||||
|
||||
**图4.1 系统总体架构图（论文定稿阶段插入）**
|
||||
|
||||
### 4.2 功能结构设计
|
||||
|
||||
#### 4.2.1 顾客端功能结构
|
||||
|
||||
顾客端围绕购物路径设计：商品浏览/检索 → 收藏/加购 → 下单支付（本系统先实现订单生成）→ 订单管理 → 物流与售后。个人中心提供资料维护能力。
|
||||
|
||||
#### 4.2.2 商家端功能结构
|
||||
|
||||
商家端围绕“经营与履约”设计：经营概览 → 商品管理 → 订单处理 → 发货/退款处理 → 评价与物流查看 → 库存记录追踪。该结构强调履约效率与运营透明度。
|
||||
|
||||
#### 4.2.3 管理员端功能结构
|
||||
|
||||
管理员端围绕“平台治理”设计：数据概览 → 订单管理与风险识别 → 审核管理（商家入驻、退款、发货）→ 用户管理 → 商品审核 → 轮播图配置 → 数据查看（评价、物流、库存）。
|
||||
|
||||
**图4.2 三端功能结构图（论文定稿阶段插入）**
|
||||
|
||||
### 4.3 数据库设计
|
||||
|
||||
#### 4.3.1 概念设计
|
||||
|
||||
根据业务需求，系统核心实体包括：用户、商品、购物车项、收藏项、订单、订单明细、评价、物流记录、库存记录、商家申请、轮播图。实体间主要关系如下：
|
||||
|
||||
- 用户与订单：一对多；
|
||||
- 订单与订单明细：一对多；
|
||||
- 商品与订单明细：一对多；
|
||||
- 商家与商品：一对多；
|
||||
- 订单与物流记录：一对多；
|
||||
- 用户与商家申请：一对多（在业务语义上可视为一次或多次申请记录）。
|
||||
|
||||
**图4.3 系统 E-R 图（论文定稿阶段插入）**
|
||||
|
||||
#### 4.3.2 逻辑设计
|
||||
|
||||
依据概念模型转化得到主要关系模式：
|
||||
|
||||
1. `users(id, username, password, role, nickname, phone, address, token, enabled, created_at, updated_at)`
|
||||
2. `product(id, name, category, description, price, stock, image_url, merchant_id, approved, created_at, updated_at)`
|
||||
3. `cart_item(id, customer_id, product_id, quantity)`
|
||||
4. `favorite(id, customer_id, product_id)`
|
||||
5. `orders(id, order_no, customer_id, merchant_id, total_amount, status, address, logistics_info, refund_reason, created_at, updated_at)`
|
||||
6. `order_item(id, order_id, product_id, product_name, quantity, unit_price)`
|
||||
7. `review(id, order_id, product_id, customer_id, rating, content, created_at)`
|
||||
8. `logistics_record(id, order_id, merchant_id, status, note, created_at)`
|
||||
9. `inventory_record(id, product_id, merchant_id, change_qty, note, created_at)`
|
||||
10. `merchant_application(id, user_id, qualification, status, remark, created_at, updated_at)`
|
||||
11. `banner(id, image_url, link_url, sort_no, enabled)`
|
||||
|
||||
#### 4.3.3 物理设计
|
||||
|
||||
以下列出部分关键物理表设计示例。
|
||||
|
||||
**表4.1 用户表（users）**
|
||||
|
||||
| 字段名称 | 字段含义 | 类型 | 约束 |
|
||||
|---|---|---|---|
|
||||
| id | 用户ID | BIGINT | 主键，自增 |
|
||||
| username | 登录账号 | VARCHAR(50) | 唯一，非空 |
|
||||
| password | 密码 | VARCHAR(100) | 非空 |
|
||||
| role | 角色 | VARCHAR(20) | 非空 |
|
||||
| token | 登录令牌 | VARCHAR(100) | 可空 |
|
||||
| enabled | 启用状态 | BIT | 默认1 |
|
||||
|
||||
**表4.2 商品表（product）**
|
||||
|
||||
| 字段名称 | 字段含义 | 类型 | 约束 |
|
||||
|---|---|---|---|
|
||||
| id | 商品ID | BIGINT | 主键，自增 |
|
||||
| name | 商品名称 | VARCHAR(120) | 非空 |
|
||||
| category | 类目 | VARCHAR(50) | 可空 |
|
||||
| price | 价格 | DECIMAL(10,2) | 非空 |
|
||||
| stock | 库存 | INT | 非空 |
|
||||
| merchant_id | 商家ID | BIGINT | 非空 |
|
||||
| approved | 审核状态 | BIT | 默认0 |
|
||||
|
||||
**表4.3 订单表（orders）**
|
||||
|
||||
| 字段名称 | 字段含义 | 类型 | 约束 |
|
||||
|---|---|---|---|
|
||||
| id | 订单ID | BIGINT | 主键，自增 |
|
||||
| order_no | 订单编号 | VARCHAR(50) | 唯一，非空 |
|
||||
| customer_id | 顾客ID | BIGINT | 非空 |
|
||||
| merchant_id | 商家ID | BIGINT | 非空 |
|
||||
| total_amount | 订单总额 | DECIMAL(10,2) | 非空 |
|
||||
| status | 订单状态 | VARCHAR(30) | 非空 |
|
||||
| logistics_info | 物流信息 | VARCHAR(255) | 可空 |
|
||||
|
||||
**表4.4 订单明细表（order_item）**
|
||||
|
||||
| 字段名称 | 字段含义 | 类型 | 约束 |
|
||||
|---|---|---|---|
|
||||
| id | 明细ID | BIGINT | 主键，自增 |
|
||||
| order_id | 订单ID | BIGINT | 非空 |
|
||||
| product_id | 商品ID | BIGINT | 非空 |
|
||||
| product_name | 商品名称 | VARCHAR(120) | 非空 |
|
||||
| quantity | 数量 | INT | 非空 |
|
||||
| unit_price | 单价 | DECIMAL(10,2) | 非空 |
|
||||
|
||||
### 4.4 接口与权限设计
|
||||
|
||||
#### 4.4.1 接口分层与命名规范
|
||||
|
||||
系统接口按职责划分为四类：
|
||||
|
||||
- `/api/auth`：认证与个人信息；
|
||||
- `/api/public`：公开商品与轮播信息；
|
||||
- `/api/customer`：顾客业务；
|
||||
- `/api/merchant`：商家业务；
|
||||
- `/api/admin`：管理员业务。
|
||||
|
||||
响应模型采用统一包装结构，包含 `success`、`data`、`message` 等字段（依据后端公共响应类实现）。该设计可降低前后端联调复杂度并提高错误处理一致性。
|
||||
|
||||
#### 4.4.2 认证机制设计
|
||||
|
||||
请求进入后端时先由拦截器检查路径是否属于公开路径，若非公开路径则读取 `X-Token` 并查找用户记录。若 Token 缺失、无效或用户被禁用，接口返回未授权错误。校验成功后将用户对象注入请求上下文，供控制器和服务层读取。
|
||||
|
||||
#### 4.4.3 角色权限设计
|
||||
|
||||
系统角色包括：
|
||||
|
||||
- `CUSTOMER`：顾客权限，主要进行购物相关操作；
|
||||
- `MERCHANT`：商家权限，主要进行商品与订单履约操作；
|
||||
- `ADMIN`：管理员权限，负责平台治理与审核。
|
||||
|
||||
服务层通过统一角色校验方法拦截越权请求，保障业务边界安全。
|
||||
|
||||
### 4.5 关键流程设计
|
||||
|
||||
#### 4.5.1 顾客下单流程
|
||||
|
||||
顾客在购物车确认商品后发起下单请求，系统按商品逐项校验库存并计算总价，创建订单主记录和订单明细记录，同时扣减库存并写入库存变更流水，最后清空对应购物车数据。
|
||||
|
||||
#### 4.5.2 商家发货流程
|
||||
|
||||
商家在订单列表中选择目标订单，填写发货备注后提交。系统验证订单归属和状态后更新订单状态为已发货，并新增物流记录。
|
||||
|
||||
#### 4.5.3 退款处理流程
|
||||
|
||||
顾客提交退款申请后，订单状态进入退款申请中。商家和管理员可依据业务规则进行审核；审核通过则更新退款状态并记录备注。
|
||||
|
||||
**图4.4 关键业务序列图（论文定稿阶段插入）**
|
||||
|
||||
### 4.6 界面设计
|
||||
|
||||
系统界面遵循“角色聚焦、操作路径短、反馈明确”的设计原则：
|
||||
|
||||
- 顾客端页面强调商品展示、加购和订单追踪；
|
||||
- 商家端页面强调经营概览、订单处理和库存记录；
|
||||
- 管理员端页面强调审核、治理与数据可视化。
|
||||
|
||||
界面组件统一采用 Arco Design，保证交互一致性和视觉规范性。关键页面包括登录页、商品列表页、购物车页、订单页、商家后台概览页、管理员审核页等。
|
||||
|
||||
---
|
||||
|
||||
## 第5章 萌贝母婴商城系统实现
|
||||
|
||||
### 5.1 用户认证与基础模块实现
|
||||
|
||||
#### 5.1.1 注册与登录实现
|
||||
|
||||
系统在认证模块中提供注册与登录接口。注册时保存用户账号、密码和默认角色；登录时验证账号密码并生成 Token，写入用户记录后返回给前端。前端在本地存储 Token，并在后续请求头中统一携带。
|
||||
|
||||
该实现方案降低了认证复杂度，适用于教学与中小规模业务场景。相比完全无状态鉴权方案，本系统可通过数据库直接失效 Token，便于运维管理。
|
||||
|
||||
#### 5.1.2 个人信息维护实现
|
||||
|
||||
用户登录后可通过个人中心查看并修改昵称、电话、地址等信息。后端通过当前登录用户上下文定位目标记录，避免跨用户修改风险。该模块为后续订单收货与客服沟通提供基础数据支撑。
|
||||
|
||||
### 5.2 顾客端功能实现
|
||||
|
||||
#### 5.2.1 商品浏览与搜索
|
||||
|
||||
顾客可在首页浏览商品列表，并使用关键词进行检索。前端通过公开接口获取商品数据并渲染卡片列表，支持快速查看价格、库存和基础介绍信息。该功能提升了用户找货效率，是交易链路的入口模块。
|
||||
|
||||
#### 5.2.2 购物车与立即购买
|
||||
|
||||
购物车模块支持加购、数量调整与删除；立即购买模块支持跳过购物车直接创建订单。下单前顾客需填写或确认收货地址，后端在提交订单时进行库存校验与金额计算，确保交易数据准确。
|
||||
|
||||
#### 5.2.3 订单管理与售后处理
|
||||
|
||||
顾客可查看订单列表、订单明细、物流信息，并在允许状态下申请退款、修改地址或删除历史订单。该模块覆盖了订单生命周期中的主要用户操作，显著提升售后体验。
|
||||
|
||||
#### 5.2.4 收藏与评价
|
||||
|
||||
收藏模块帮助用户沉淀意向商品，评价模块允许顾客对购买商品进行反馈。评价数据可被商家和管理员查看，为商品优化和平台治理提供参考。
|
||||
|
||||
### 5.3 商家端功能实现
|
||||
|
||||
#### 5.3.1 商家概览
|
||||
|
||||
商家概览模块汇总订单数量、销售额、类目数据与热销趋势，帮助商家快速掌握经营状态。该模块通过后端聚合接口返回统计结果，前端以图表和卡片方式展示。
|
||||
|
||||
#### 5.3.2 商品管理
|
||||
|
||||
商家可新增、编辑和删除商品。保存商品时后端会绑定当前商家 ID，防止跨商家数据污染。管理员可对商品进行审核，形成“上架信息可控、商品质量可管”的平台机制。
|
||||
|
||||
#### 5.3.3 订单履约与退款处理
|
||||
|
||||
商家在订单管理中可执行发货并记录备注，也可处理退款申请。系统在服务层进行订单归属与状态校验，避免非法操作。履约链路与物流记录联动，提升交易透明度。
|
||||
|
||||
#### 5.3.4 库存记录与物流查看
|
||||
|
||||
库存记录模块展示商品库存变更明细，帮助商家进行库存核对。物流查看模块可追踪订单履约过程，减少因信息不对称产生的售后争议。
|
||||
|
||||
### 5.4 管理员端功能实现
|
||||
|
||||
#### 5.4.1 订单治理与风控
|
||||
|
||||
管理员可查看全部订单并执行状态更新，系统支持风险订单列表、退款审核与发货审核等治理能力。通过后台治理机制，平台可对异常交易进行及时干预。
|
||||
|
||||
#### 5.4.2 商家入驻审核
|
||||
|
||||
顾客提交商家申请后，管理员可在申请列表中进行审核。审核结果直接影响商家角色业务权限，有助于提升平台商家质量与合规性。
|
||||
|
||||
#### 5.4.3 用户与商品管理
|
||||
|
||||
管理员可管理用户账户状态、增删改查用户信息，并对商品进行统一审核和维护。该能力是平台治理的核心基础。
|
||||
|
||||
#### 5.4.4 轮播图与运营配置
|
||||
|
||||
管理员可配置首页轮播图，提升运营活动触达能力。该模块在营销场景中具有较高实用价值，便于平台开展阶段性推广活动。
|
||||
|
||||
### 5.5 关键业务链路实现结果
|
||||
|
||||
#### 5.5.1 从浏览到下单链路
|
||||
|
||||
系统已实现完整的顾客购物主链路：浏览商品、加入购物车、提交订单、查看订单。链路中的关键数据对象（商品、订单、订单明细、库存记录）可关联追踪，业务闭环完整。
|
||||
|
||||
#### 5.5.2 从下单到履约链路
|
||||
|
||||
商家可查看订单并完成发货，系统同步生成物流记录，顾客可查看物流详情。该链路提升了订单履约的可视化程度。
|
||||
|
||||
#### 5.5.3 从异常到治理链路
|
||||
|
||||
退款申请、风险订单、商家审核等场景由管理员侧进行治理，形成“业务执行 + 平台监管”双轮驱动模式，提升平台稳定性与可信度。
|
||||
|
||||
---
|
||||
|
||||
## 第6章 萌贝母婴商城系统测试
|
||||
|
||||
### 6.1 测试环境与测试策略
|
||||
|
||||
#### 6.1.1 测试环境
|
||||
|
||||
- 操作系统：macOS / Windows（开发与演示环境）；
|
||||
- JDK 版本：17；
|
||||
- 后端框架：Spring Boot 3.3.5；
|
||||
- 前端框架：Vue3 + Vite；
|
||||
- 数据库：MySQL 8；
|
||||
- 浏览器：Chrome、Edge（主）。
|
||||
|
||||
#### 6.1.2 测试策略
|
||||
|
||||
系统测试采用“模块测试 + 业务流程测试 + 权限测试 + 兼容性测试”组合策略：
|
||||
|
||||
1. 模块测试验证接口功能正确性；
|
||||
2. 流程测试验证跨模块业务链路完整性；
|
||||
3. 权限测试验证角色访问控制有效性；
|
||||
4. 兼容性测试验证主流浏览器访问可用性。
|
||||
|
||||
### 6.2 功能测试
|
||||
|
||||
#### 6.2.1 认证功能测试
|
||||
|
||||
| 测试编号 | 测试内容 | 输入条件 | 预期结果 | 测试结果 |
|
||||
|---|---|---|---|---|
|
||||
| T001 | 用户登录成功 | 正确账号密码 | 返回Token并跳转角色主页 | 通过 |
|
||||
| T002 | 登录失败 | 错误密码 | 返回错误提示 | 通过 |
|
||||
| T003 | 未登录访问受限接口 | 无Token | 返回未授权 | 通过 |
|
||||
|
||||
#### 6.2.2 商品与购物车测试
|
||||
|
||||
| 测试编号 | 测试内容 | 输入条件 | 预期结果 | 测试结果 |
|
||||
|---|---|---|---|---|
|
||||
| T101 | 商品检索 | 关键字“奶粉” | 返回匹配商品列表 | 通过 |
|
||||
| T102 | 加入购物车 | productId+quantity | 购物车新增记录 | 通过 |
|
||||
| T103 | 删除购物车项 | 指定productId | 购物车项移除 | 通过 |
|
||||
|
||||
#### 6.2.3 订单与售后测试
|
||||
|
||||
| 测试编号 | 测试内容 | 输入条件 | 预期结果 | 测试结果 |
|
||||
|---|---|---|---|---|
|
||||
| T201 | 购物车结算下单 | 有效商品与地址 | 生成订单与明细 | 通过 |
|
||||
| T202 | 修改订单地址 | 可修改状态订单 | 地址更新成功 | 通过 |
|
||||
| T203 | 申请退款 | 已支付订单 | 状态改为退款申请中 | 通过 |
|
||||
| T204 | 查看物流 | 已发货订单 | 返回物流记录 | 通过 |
|
||||
|
||||
#### 6.2.4 商家功能测试
|
||||
|
||||
| 测试编号 | 测试内容 | 输入条件 | 预期结果 | 测试结果 |
|
||||
|---|---|---|---|---|
|
||||
| T301 | 商家新增商品 | 合法商品信息 | 商品保存成功 | 通过 |
|
||||
| T302 | 商家发货 | 商家订单+备注 | 状态更新并写入物流 | 通过 |
|
||||
| T303 | 商家处理退款 | 退款申请订单 | 状态按操作变更 | 通过 |
|
||||
|
||||
#### 6.2.5 管理员功能测试
|
||||
|
||||
| 测试编号 | 测试内容 | 输入条件 | 预期结果 | 测试结果 |
|
||||
|---|---|---|---|---|
|
||||
| T401 | 用户管理 | 新增/删除用户 | 数据正确变更 | 通过 |
|
||||
| T402 | 商家申请审核 | 待审核申请 | 状态更新成功 | 通过 |
|
||||
| T403 | 商品审核 | 审核商品状态 | 审核状态变更 | 通过 |
|
||||
|
||||
### 6.3 安全性与兼容性测试
|
||||
|
||||
#### 6.3.1 安全性测试
|
||||
|
||||
- Token 缺失或非法时，受限接口拒绝访问；
|
||||
- 顾客账号访问商家/管理员接口时，系统返回权限错误；
|
||||
- 参数缺失、状态不合法的请求会被业务规则拦截；
|
||||
- 关键操作通过统一异常处理返回可读错误信息。
|
||||
|
||||
#### 6.3.2 兼容性测试
|
||||
|
||||
在 Chrome 与 Edge 浏览器下，登录、商品浏览、下单、后台管理等核心页面渲染正常，交互流程可用。不同分辨率下布局保持基本稳定，满足课程项目展示需求。
|
||||
|
||||
### 6.4 测试结果分析
|
||||
|
||||
测试结果表明，系统在核心功能、角色权限控制和主要流程链路上运行稳定，能够满足设计预期。当前仍存在可优化空间：
|
||||
|
||||
1. 缺少在线支付闭环，仅实现订单生成与状态流转；
|
||||
2. 库存预警与自动补货机制尚未实现；
|
||||
3. 推荐与个性化能力不足，主要依赖基础检索；
|
||||
4. 运营分析维度可进一步增强。
|
||||
|
||||
总体而言，系统已达到毕业设计“可运行、可验证、可扩展”的目标。
|
||||
|
||||
---
|
||||
|
||||
## 第7章 结论与展望
|
||||
|
||||
### 7.1 研究结论
|
||||
|
||||
本文围绕母婴电商场景，完成了萌贝母婴商城系统的分析、设计、实现与测试工作。研究成果主要体现在以下方面：
|
||||
|
||||
1. 构建了面向顾客、商家、管理员三角色的业务系统，形成较完整的交易与治理闭环；
|
||||
2. 基于 Spring Boot + Vue3 实现了前后端分离架构，模块边界清晰，具备较好可维护性；
|
||||
3. 完成了用户、商品、订单、物流、库存、审核等关键数据模型设计与落地；
|
||||
4. 通过测试验证系统在功能完整性、权限有效性和流程可用性方面符合预期。
|
||||
|
||||
本研究证明了在教学项目与中小规模业务背景下，采用成熟开源技术栈能够快速实现具备工程价值的垂直电商系统。
|
||||
|
||||
### 7.2 不足与改进方向
|
||||
|
||||
尽管系统已实现主要目标，但仍存在以下不足：
|
||||
|
||||
- 支付模块未接入真实网关；
|
||||
- 订单风控规则仍较基础；
|
||||
- 统计分析多为聚合结果，缺少深度运营看板；
|
||||
- 缺少自动化测试体系与持续交付流程。
|
||||
|
||||
未来可从以下方向持续优化：
|
||||
|
||||
1. 接入支付网关并完善退款对账机制；
|
||||
2. 引入推荐算法与用户画像，提高转化效率；
|
||||
3. 增加库存预警、活动营销、消息通知等能力；
|
||||
4. 建立自动化测试与 CI/CD 流程，提高交付质量；
|
||||
5. 在安全层面引入更完善的 Token 生命周期管理与审计日志体系。
|
||||
|
||||
---
|
||||
|
||||
## 参考文献
|
||||
|
||||
[1] Spring Team. Spring Boot Reference Documentation[EB/OL]. https://docs.spring.io/spring-boot/docs/current/reference/html/, 2026-02-28.
|
||||
|
||||
[2] Spring Team. Spring Security Reference[EB/OL]. https://docs.spring.io/spring-security/reference/, 2026-02-28.
|
||||
|
||||
[3] Oracle. MySQL 8.0 Reference Manual[EB/OL]. https://dev.mysql.com/doc/refman/8.0/en/, 2026-02-28.
|
||||
|
||||
[4] Evan You, Vue Team. Vue.js Documentation[EB/OL]. https://vuejs.org/guide/introduction.html, 2026-02-28.
|
||||
|
||||
[5] Pinia Team. Pinia Official Documentation[EB/OL]. https://pinia.vuejs.org/, 2026-02-28.
|
||||
|
||||
[6] Jones M, Bradley J, Sakimura N. JSON Web Token (JWT): RFC 7519[S]. IETF, 2015.
|
||||
|
||||
[7] Black Horse Programmer. Spring Boot 企业级开发教程[M]. 北京: 人民邮电出版社, 2024.
|
||||
|
||||
[8] 郑阿奇. MySQL 数据库教程[M]. 北京: 人民邮电出版社, 2024.
|
||||
|
||||
[9] 杨玉, 刘杰举. 基于Spring Boot与Vue的物业管理系统设计与实现[J]. 鞋类工艺与设计, 2025, 5(14): 114-116.
|
||||
|
||||
[10] 汤智宏. 基于 SpringBoot+Vue 的线上书店设计与实践[J]. 电脑编程技巧与维护, 2025(09): 71-73.
|
||||
|
||||
[11] 冯赛赛, 郝婷. 影院管理系统的设计与实现[J]. 福建电脑, 2025, 41(05): 68-72.
|
||||
|
||||
[12] 项露芬, 孙佳怡, 李梦婷. 基于Vue和Node.js的音乐门票管理系统的设计与实现[J]. 现代信息科技, 2025, 9(11): 96-101.
|
||||
|
||||
[13] 闫俊甫. 基于 Spring Boot 和 Element UI 的中小型超市 ERP 系统的开发[J]. 电脑知识与技术, 2025, 21(16): 48-50.
|
||||
|
||||
[14] 张磊. 基于 B/S 架构的矿区生态监管系统平台设计与实现[J]. 河南科技, 2025, 52(16): 17-22.
|
||||
|
||||
[15] Gyan O J, Raheem A T, Ogundipe O M, et al. Enhancing Security Practices across the Software Development Lifecycle: The Role of Artificial Intelligence[J]. Asian Journal of Research in Computer Science, 2025, 18(10): 101-114.
|
||||
|
||||
---
|
||||
|
||||
## 致谢
|
||||
|
||||
本课题从立项到论文初稿完成，离不开学院老师和同学们的支持。首先感谢指导教师在选题定位、技术路线、文档规范和阶段性评审中的耐心指导，使我能够在有限时间内持续修正方向、完善系统设计并推动实现落地。其次感谢项目组同学在需求讨论、页面联调、测试验证中的配合与建议，许多关键问题都在交流中得到解决。最后感谢家人对我学习与实践的理解和支持，使我能够保持稳定投入并完成本次毕业设计。
|
||||
|
||||
由于个人经验和时间限制，论文中仍存在不足，后续将继续优化系统功能与文档质量，力求在答辩前形成更高质量的定稿成果。
|
||||
|
||||
---
|
||||
|
||||
## 附录
|
||||
|
||||
### 附录A：项目目录结构（节选）
|
||||
|
||||
- `/backend`：后端工程（控制器、服务、领域模型、仓储、配置）
|
||||
- `/frontend`：前端工程（视图、路由、接口封装、状态管理）
|
||||
- `/sql/init.sql`：数据库初始化脚本
|
||||
- `/example`：论文规范样例与排版脚本
|
||||
|
||||
### 附录B：默认测试账号
|
||||
|
||||
- 管理员：`admin / 123456`
|
||||
- 商家：`merchant1 / 123456`
|
||||
- 顾客：`customer1 / 123456`
|
||||
|
||||
### 附录C：主要接口前缀
|
||||
|
||||
- `/api/auth`：注册登录与个人信息
|
||||
- `/api/public`：公开商品与轮播信息
|
||||
- `/api/customer`：顾客业务
|
||||
- `/api/merchant`：商家业务
|
||||
- `/api/admin`：管理员业务
|
||||
|
||||
### 附录D：术语说明
|
||||
|
||||
- **前后端分离**：前端界面与后端服务独立部署，通过 API 通信。
|
||||
- **角色权限控制**：基于用户角色约束可访问的功能与接口。
|
||||
- **业务闭环**：从需求入口到结果反馈形成完整可追踪流程。
|
||||
- **库存流水**：记录库存变化来源与数量的日志型数据。
|
||||
Reference in New Issue
Block a user