做毕业设计的时候，很多同学会在选题上纠结很久。宠物购买管理系统这个题目，其实是一个很经典又很稳妥的选择——SSM框架加Vue前后端分离，覆盖了用户注册登录、宠物浏览、加入购物车、下单购买、订单管理、后台管理这一整套业务闭环，既能体现技术栈的完整性，又不会像纯增删改查那样显得单薄。这篇博文围绕2026届毕业设计、基于SSM和Vue的宠物购买管理系统，把需求分析、数据库设计、后端接口到前端页面的整个实现过程捋一遍，同时分享一些我实际操作中踩过的坑和总结的经验，给正在做毕设或者想复现类似项目的人做一个参考。
我见过不少同学一上来就急着写代码，结果写到一半发现需求没理清，表结构不合理，后面全是返工。所以这篇文章我会按照"思路拆解 -> 框架搭建 -> 数据库设计 -> 核心功能实现 -> 问题排查"的顺序来写，其中每个环节的设计理由都会尽量讲清楚，而不只是贴代码。尤其是SSM和Vue之间如何配合、宠物购买场景里订单状态怎么流转、后台权限怎么控制这些问题，值得细说。
1. 项目整体设计与思路拆解
1.1 系统到底要解决什么核心问题
先想清楚一个事情：宠物购买管理系统，本质上做的不是"宠物展示"，而是一整套交易流程的线上化。用户进入系统，看到宠物列表，点击详情，加入购物车，确认订单，模拟支付，然后管理自己的订单；管理员进入后台，管理宠物上下架、处理订单发货、管理用户、管理公告和分类。这套流程和电商系统非常相似，只是业务对象从普通商品变成了宠物，所以我在给宠物实体设计字段时，特意增加了品种、年龄、性别、疫苗情况这些宠物特有的属性，而不是直接照搬一个通用商品表。
需求拆解下来大致可以分为两个端：用户端和管理员端。用户端包括注册登录、宠物资讯浏览与搜索、宠物详情查看、购物车、下单、确认收货、个人中心；管理员端包括宠物信息管理、分类管理、订单处理、用户管理、公告发布。有些需求分析还会加入收藏、评论、销售统计图表，这个要看学校论文的要求来定，但从系统完整度来说，加入销售统计和宠物收藏能让整个项目的亮点更突出，答辩的时候也更有话可说。
我个人的建议是，在第一轮需求梳理时用一张表格把角色、功能模块、核心操作写清楚，然后给每个模块标注优先级。比如"宠物浏览"和"购买下单"是P0，"收藏、评论"是P1，"数据统计、公告"是P2。这样后面开发的时候不会临时加需求，也不会因为功能太多导致核心链路做不完。
1.2 技术选型：为什么是SSM + Vue而不是其他组合
选择SSM框架加Vue，首先是因为这是目前高校毕业设计中最主流、参考资料最多的一套组合。SSM指的是Spring、Spring MVC、MyBatis这三个框架，它们各自负责不同的角色：Spring管IOC容器和事务，Spring MVC管HTTP请求的路由分发，MyBatis管数据库操作。三者配合起来，后端分层结构和业务代码的职责边界非常清晰，答辩时也很容易自圆其说。
前端选择Vue，理由也很直接。Vue的渐进式框架特性决定了它既可以做一个简单的页面套壳，也可以做成完整的组件化单页应用。宠物购买管理系统的交互场景并不算特别复杂，用Vue加Vue Router加Vuex或者Pinia就能把页面路由、全局状态管理、组件通信全部覆盖。最关键的还是Vue的双向数据绑定，比如用户在购物车页面修改购买数量时，前端不用手动操作DOM，数据变了页面自动就变了，开发效率高很多。
这里顺带对比一下为什么不选Spring Boot。2026年这个时间点上，很多学校已经接受Spring Boot作为毕设框架了，如果学校不强制要求"SSH"或者"SSM"这种经典组合，用Spring Boot确实更省事。但SSM仍然有它的优势：它在打包部署时的结构更直白，很多老版本的教程资料都是基于SSM的XML配置写的，出了问题网上查答案也更好查。我的建议是看学校往届论文的框架要求，如果允许Spring Boot，那可以把它作为SSM的替代方案写在论文的可行性分析里，实际代码还是用SSM，风险最低。
1.3 系统整体架构与开发环境
整个系统的请求流转可以简单概括为：Vue页面发送HTTP请求，经Vue Router路由匹配到视图组件，组件内部调用axios发请求到后端；后端先由Spring MVC的DispatcherServlet拦截请求，交给对应的Controller方法，Controller调用Service层处理业务逻辑，Service层依赖Mapper接口操作数据库；MyBatis在Mapper XML中写SQL与数据库交互，查询结果逐层返回，最终以JSON格式响应给前端。
开发环境这部分没什么花头，我用的是JDK 1.8、Maven 3.6、MySQL 5.7或8.0都行、Vue 2或Vue 3看个人习惯。实际开发中有一个点容易被忽略，就是后端接口返回的数据格式。我一开始写接口时直接返回了一个局部数据对象，前端拿到之后才发现缺少统一的状态码和消息字段，后面很难扩展。所以我后来规定所有的接口统一返回后端封装的Result对象，里面包含code、message、data三个字段，这样前端axios拦截器只需要判断code就能做统一的错误提示，不用每个接口都单独处理。
2. 后端SSM框架的落地实现
2.1 Spring、Spring MVC、MyBatis是怎么互相配合的
理解SSM的协作机制是后端开发不迷路的关键。Spring容器是整套系统的心脏，UserMapper、UserService、UserController这些类的对象都由Spring去创建并管理它们的生命周期。Spring MVC则是接收HTTP请求的"前台接待"，用户从前端页面发送请求进来，DispatcherServlet会根据URL去匹配HandlerMapping，找到对应的Controller方法，方法执行完后返回JSON数据。而MyBatis是"数据接线员"，负责把数据库表映射为Java对象，执行SQL并返回结果。
配置这块有XML和注解两种方式。SSM老项目通常用XML集中配置数据源、事务管理、Mapper扫描等，新一代写法更偏向注解配置。我建议在代码里尽量用注解，例如ServiceImpl类上用@Service标注，Controller上用@RestController，Mapper接口用@Mapper注解，而XML文件只留一些复杂查询的SQL语句。这样代码看起来干净，论文里的配置说明也好写。
再补充一个事务的细节：购买下单这个操作涉及多张表的写入，比如插入订单表、更新库存、清空购物车，任何一个环节失败都可能造成数据不一致。所以下单的Service方法必须加上@Transactional事务注解，保证要么全部成功，要么全部回滚。有些同学在答辩的时候被问到"你这个系统怎么保证数据一致性"，如果代码里连事务都没加，这个问题基本就答不上来。
2.2 后端分层：Controller、Service、Mapper各自的职责
后端代码的分层结构能不能写清楚，直接决定了后期维护和论文写作的顺畅程度。我常用的包结构是：controller存放接口层代码，service存放业务逻辑接口，service.impl存放业务逻辑实现，mapper存放MyBatis接口，entity存放实体类，common存放统一返回结果和异常处理类。
以"用户下单"这个场景为例，Controller层的责任只是接收前端传递过来的订单数据并调用Service，它不应该写任何业务计算；Service层负责核心逻辑，比如判断宠物库存、计算订单总金额、生成订单号；Mapper层只做最简单的数据库插入和查询工作。很多新手写代码习惯于把SQL写在Controller里面，看起来代码变短了，但一旦业务逻辑变复杂，这种代码就没法维护了，论文里的模块设计也不好画图。
我还习惯在Service实现里加必要的参数校验。因为前端传过来的数据是不可信的，你以为price是一个数字，前端可能传了一个NaN或者负值。如果只在Controller层做校验，就会导致以后每次新加一个入口就要重新写一遍校验。更合理的做法是Controller只做参数接收和调用，Service做业务校验，数据库层通过唯一约束和字段类型兜底。三层各管各的，清晰又安全。
2.3 后端接口设计与统一返回格式
接口设计不要求多么高大上，但一定要统一。宠物购买管理系统里最常见的接口就是宠物列表查询、宠物详情查询、登录注册接口、购物车接口、订单接口、后台管理接口。接口的URL我一般按照restful风格来命名，例如获取宠物列表用GET /api/pet/list，通过编号获取详情用GET /api/pet/info/{id}，提交订单用POST /api/order/create。
统一返回格式这件事我真要强调一下。一开始我写的接口是这种直接返回HashMap的写法，前端拿到数据之后发现不知道是成功还是失败，因为每个接口的返回结构都不一样。后来我封装了Result对象，定义好静态方法Result.ok(data)和Result.error(message)，所有接口全部走同一个返回结构。这样前端axios的响应拦截器里，只需要判断res.code === 200就继续执行，否则弹出错误信息。整个联调过程顺畅了非常多。
3. 前端Vue框架的页面搭建
3.1 Vue项目的初始化与目录结构
前端的工程化流程是：先通过Vue CLI创建一个新项目，然后安装Vue Router和axios，如果需要全局状态管理再安装Vuex或者Pinia。在项目的src目录下，我习惯按功能模块去组织页面，例如views下面拆成user、admin、cart、order几个子目录，components目录放公共组件，比如宠物卡片组件、分页组件、导航栏组件，api目录放所有的请求接口封装。
Vue的组件化开发在宠物购买系统里有非常典型的应用：宠物列表页和后台的宠物管理页虽然业务不同，但它们都有"展示宠物信息"的需求，所以我把宠物卡片抽成一个公共组件PetCard.vue，传入pet对象，渲染宠物图片、名字、价格和简介。前台页面点击卡片跳转到详情，后台页面点击卡片跳转到编辑，用法完全复用。组件化的好处不只是减少代码量，更重要的是让页面的结构清晰，答辩时讲起来也更有条理。
Vue Router的路由配置需要区分用户端和管理员端。用户端的路由直接登录即可访问，但管理员后台的访问必须做权限控制。我采用的是在路由对象上增加meta信息标记哪些页面需要admin权限，然后通过Vue Router的全局前置守卫beforeEach去判断当前登录用户的角色，如果没有登录就跳转登录页，如果登录了但是普通用户就直接拦截。这个写法不复杂，但很实用，能体现权限控制的思路。
3.2 页面交互与接口对接的几个关键细节
前后端联调时最容易出现的几个问题，我在这里提前说明。第一是跨域问题，前端运行在8080端口，后端运行在8081端口，浏览器会拦截跨域请求。解决办法是在后端加一个Cors过滤器和配置类，允许前端地址访问后端接口，或者在前端通过Vue的devServer配置代理转发。推荐用后端统一配置Cors的方式，部署的时候对前端更友好。
第二是整个项目中的请求拦截与错误处理。我建议在axios实例的请求拦截器里统一加上token，这样每个请求都自动携带用户登录凭证。后端需要对token进行解析，判断当前操作的用户的编号，再用这个编号去查询自己的数据。比如查看订单列表这个接口，如果不从token里取用户编号，而让前端把用户编号当作参数传过来，那么只要有人改一下参数就能看到别人的订单，这是严重的安全漏洞。虽然这个项目是毕设，但建议在论文里把这个校验逻辑写清楚，能给答辩加分。
第三是Vue中的数据响应式问题。如果直接给对象新增一个属性，视图不会自动更新，这种情况通常出现在把后端返回的数据塞给对象时。现在的Vue 3底层用Proxy，已经基本解决了这个问题，但如果用的是Vue 2，就要注意使用Vue.set来给响应式对象添加新属性，否则会出现数据显示不出来的诡异现象。
3.3 页面设计：从登录到下单的完整用户路径
整个用户端的核心路径是：注册/登录 -> 首页浏览宠物 -> 宠物详情 -> 加入购物车 -> 确认订单 -> 模拟支付 -> 订单列表 -> 确认收货。页面上需要注意的细节不少，我挑几个重点说。
首页设计上，宠物展示区要有筛选和分页。筛选条件包括宠物分类（猫、狗、小宠）、价格区间、品种关键词。搜索框支持关键词匹配宠物名称和品种。这部分用到的技术是多个查询条件的动态拼接，也就是MyBatis的动态SQL。前端传一个查询对象过来，后端判断如果某个字段不为空就拼接对应的WHERE条件。这样做既简单又实用，比单独写十几个查询接口要好得多。
宠物详情页要展示的信息包括宠物图片、名称、品种、年龄、性别、疫苗状态、价格、库存数量和详情描述。我之前做的时候忽略了库存数量的回显，导致用户把宠物全部加购完之后，前端还不知道库存已经不足，直到下单时才提示失败。后来我在宠物实体里加上stock字段，详情页在加载宠物信息的同时把库存一起带回，在前端做立即判断，如果stock小于1就禁用购买按钮。
购物车页面的要点是批量选中计算总价、修改数量、删除商品。购物车数据我建议保存在后端数据库表里，而不是存在浏览器本地。虽然本地存储实现起来更简单，但这样用户换一台设备购物车就没了，而且论文里就没有"购物车模块"可写了。既然做的是毕设项目，该有的业务完整度还是要有。
4. 数据库设计与核心表结构
4.1 核心数据表怎么设计才不容易返工
数据库设计是很多人容易草率对待的部分，其实它才是整个系统的地基。宠物购买管理系统主要需要这些表：用户表、管理员表、宠物分类表、宠物信息表、购物车表、订单表、订单详情表、公告表。如果扩展了收藏和评论功能，还要加收藏表和评论表。
用户表的核心字段是用户编号、用户名、密码、昵称、手机号、地址、注册时间。密码我建议用加密，实际项目中推荐使用MD5加盐或者BCrypt加密。虽然毕设阶段的系统安全性要求不会特别高，答辩老师也可能会问到用户密码安全问题，提前做了加密就不至于现场露怯。
宠物信息表是整个系统的核心，字段包括宠物编号、名称、分类编号、品种、年龄、性别、是否接种疫苗、描述、主图、价格、库存、上下架状态、创建时间。这里有一个外键：分类编号关联分类表。我设计时选择物理外键还是逻辑外键斟酌了一下——考虑到查询性能和维护便利，最终只在逻辑上保留关联关系，没有在数据库层面强制外键约束。
订单表需要特别说明一下状态字段的设计。订单状态建议使用int类型，取值包括：0待支付、1待发货、2待收货、3已完成、4已取消。用数字而不是字符串的好处是存储空间小、比较方便，但实际开发中需要在代码里定义一个常量的枚举类，把数字映射成对应的状态名称，便于阅读和下拉展示。订单表还同时存了用户编号和收货地址的一个快照，因为用户地址后续可能会变，而订单必须保存在下单当时的信息。
4.2 购物车表和订单详情表的设计思路
购物车表一开始我只设计成了三个字段：用户编号、宠物编号、数量。实际开发中发现列表页展示购物车时还要显示宠物名称、价格、图片这些信息，如果只靠三个字段就需要每次用宠物编号去关联查询。于是我在视图层写了一个连接查询，直接把购物车表和宠物信息表关联，一次查出用户购物车列表所需的所有字段。
订单详情表的作用是记录每个订单包含哪些宠物、下单时宠物价格是多少。可能有人会问，订单详情里的价格为什么不直接关联宠物表？因为宠物价格是可能调整的，过一段时间再去查宠物表可能就是新的价格了，但订单一旦生成，金额就必须以当时的价格为准。所以订单详情表里必须冗余存一份下单时的价格和名称，同样的道理，宠物名称、图片这类字段也可以冗余进去。
数据库索引方面，我建议给用户编号、宠物编号、订单状态和订单编号加上普通索引。几个主要的联表查询字段有索引之后，数据量在1万条级别性能差距不明显，但写了总比没写好，论文的数据表设计部分会好看一些，答辩也能说得过去。
4.3 一次下单事务如何保持多表数据一致
下单这个操作牵涉多张表，我要保证订单表、订单详情表、宠物库存、购物车清理四个动作要么都成功，要么都失败。在MySQL里，如果用InnoDB引擎，本身支持事务。在SSM层，我只需要在Service层的下单方法上加上@Transactional，就能让方法内多个Mapper操作共享一个数据库事务。
下单的具体流程是：前端提交购物车中选中的宠物编号列表和数量 -> 后端创建订单主记录，状态设为待支付 -> 把每个宠物生成一条订单详情记录 -> 更新宠物表的库存减去购买数量 -> 删除购物车中对应的记录。这里需要注意库存不足的检查时机，如果用户在付款前库存被别的用户买光了，就会出现库存为负的问题。所以我用了乐观锁的思路，在更新库存的SQL里加上WHERE条件，库存充足才允许更新。
5. 核心业务模块的完整实现
5.1 登录注册与权限拦截实现
登录模块看起来简单，但从代码规范来说包含了一个完整的接口流程。注册时前端传用户名、密码、昵称、手机号，后端先判断用户名是否已经被注册。推荐的做法是给用户表的用户名字段加上唯一约束，同时在Service层通过查询做二次判断。注册接口返回成功之后，前端跳转到登录页，登录接口校验用户名密码，成功后后端生成token返回给前端。
token的生成方式有很多种，最简单的是UUID，然后把用户编号和token关联存到数据库的一张token表里，每次请求都去校验；稍微复杂一点的是用JWT，无状态，服务端不需要存储token。毕设项目用UUID加数据库存储就可以了，代码量小，逻辑直白，答辩也好解释。前端的axios拦截器统一带上Authorization请求头，后端的拦截器通过解析请求头里的token找到当前用户。
权限拦截这里要区分普通用户和管理员。用户端的大部分接口，只要登录就能访问；宠物列表和详情页其实是允许未登录用户浏览的，但如果未登录就点击"加入购物车"，前端需要跳转登录页，这个逻辑也可以在后端通过拦截器拦截未登录状态下的购物车相关请求。
5.2 宠物购买与订单状态流转
先把订单状态流转完整讲一遍。用户提交订单时状态是0（待支付），模拟支付成功之后变成1（待发货）。管理员在后台对订单点击确认发货，变成2（待收货）。用户收到货后点击确认收货，变成3（已完成）。用户如果在下单之后未支付直接取消，或者是支付前手动取消，状态变成4（已取消）。这里设定支付操作是模拟的，前端弹出一个确认框，点击确定就调用支付接口，后端直接把待支付状态改为待发货。
这个状态流转在数据库里并不复杂，重点在于前端的展示逻辑。用户端订单列表要根据状态显示不同的操作按钮，例如待支付状态显示"去支付"和"取消订单"，待发货状态只显示"申请退款"或者不显示操作，待收货状态显示"确认收货"，已完成状态不显示任何操作。我在前端是通过v-if判断订单状态字段的值来渲染按钮的。这个小细节如果不注意，用户端页面的交互会显得很乱。
管理员端的订单处理流程包括查看所有订单、按状态筛选、点击发货按钮更新状态。做得更完整一点可以加入按宠物名称、用户手机号、订单号查询订单的搜索框，这本质上就是编写多条件动态查询SQL。订单编号的生成我采用的是时间戳加用户编号拼接，比如日期时间加四位随机数，整体长度不需要太夸张，但一定要保证唯一。
5.3 后台管理：宠物上下架与销售统计
后台管理的宠物图片上传也是一个常见的亮点功能。前端使用一个上传组件，选择图片后通过接口上传到服务器本地，后端保存文件并返回图片的访问路径，前端再把路径和表单数据一起提交。部署之后上传目录放在项目根目录下，需要给静态资源映射配一个配置类，否则前端无法通过URL访问到上传的图片。
销售统计图表现阶段我用了ECharts，前端从后端拿近七天的订单数据或每月的销售总额，然后用折线图或柱状图展示出来。后端提供一个统计接口，SQL里用GROUP BY和日期函数做聚合。设计这个模块的意义在于让系统从"能用"提升到"有亮点"，答辩时直接展示图表会比干巴巴的表格有说服力得多。
宠物上下架操作本质上就是修改宠物信息的上下架状态字段。为了防止前端直接修改宠物上下架的状态值传过来一个非法数字，后端在接收到JSON数据之后需要做枚举校验，比如规定1表示上架、0表示下架，其他值一律拒绝。同样的思路也可以用在整个后台的数据修改操作上，统一做合法性校验。
6. 常见问题与排查技巧实录
6.1 前后端联调中最容易踩的五个坑
第一个坑是中文乱码。前端请求数据传过来是UTF-8编码，但后端接收的时候如果不统一字符集，就会出现请求参数中文乱码、数据库存储变成问号的情况。排查和解决办法是在后端的Spring MVC配置里设置字符编码过滤器为UTF-8，同时保证MySQL数据库连接URL里加上characterEncoding=utf8，数据表和字段的字符集也统一为utf8mb4。
第二个坑是MyBatis映射字段对不上。数据库表字段用下划线命名（例如pet_name），Java实体字段用驼峰命名（petName），如果不开启mybatis.configuration.map-underscore-to-camel-case=true，查询结果里的setter方法就会因为找不到对应字段而返回null。这个配置虽然只是在XML里加一行的事，但很多新手第一次跑通查询时数据都是空的，原因就是少了它。
第三个坑是JSON日期格式问题。后端默认返回的日期格式是Long时间戳或者ISO字符串，前端展示出来的东西不是人看的样式。解决办法是写一个Jackson配置类，统一格式化LocalDateTime为yyyy-MM-dd HH:mm:ss，这样前端就不用每个地方自己format一遍了。
第四个坑是跨域配置不生效。原因是后端有多个配置类，配置Cors的时候WebMvcConfigurer可能被框架的默认配置覆盖了。我自己被这个问题坑过一下午，排查到最后发现是配置类的位置和包扫描路径不对。后来我换成了基础方式，直接写一个Filter过滤器来处理Cors，反而没有那么多奇奇怪怪的问题。
第五个坑是端口占用。后端项目跑着跑着突然提示8081端口被占用，原因可能是上一个项目实例没有彻底停掉，或者有别的进程占用了端口。排查命令是netstat -ano查看端口对应进程，直接杀掉对应进程就行。这个小问题其实不算技术难点，但处理多了很浪费时间。
6.2 论文写作时项目相关的几个注意点
毕业设计论文如果学校对格式有模板要求，一定要按模板来。宠物购买管理系统论文的常规结构是：绪论（包括背景意义、国内外研究现状、研究内容）、相关技术介绍、需求分析（功能需求、非功能需求、可行性分析）、系统设计（总体架构、功能模块设计、数据库设计）、系统实现（用界面截图加核心代码说明）、系统测试（测试环境、功能测试用例、结果分析）、总结与展望。
我在写技术介绍时踩过一个坑，就是大段大段的原理堆砌，和后面的具体实现完全脱节。比如框架介绍写了三页，但后面的章节完全没有对应着讲解，读起来像是论文拼凑出来的。后来我调整了写法：技术介绍只写核心概念和选择理由，把和本项目相关的具体代码、配置、实现细节全部放到系统实现章节里去讲，这样前后呼应，老师翻起来也觉得顺畅很多。
系统测试章节也很重要，不要只写一两句"测试通过"。用表格整理出每个功能的操作步骤、预期结果、实际结果、结论，显得非常规范。建议至少覆盖十个以上功能点的测试用例，包括正常的登录流程、密码错误的异常流程、购买时库存不足的流程、未登录直接访问后台被拦截的流程等，测试用例越细越能体现系统的完成度和你本人对项目的熟悉程度。
6.3 若干实用开发小技巧
项目做完打包部署这一步，我也顺便多说一句。后端打成war包放到Tomcat的webapps目录下，前端执行npm run build之后把生成的dist目录里的文件复制到webapps下的某个静态目录中。注意部署到服务器之后接口地址要改成服务器的域名和端口，不能继续用本地路径。
上传图片的路径建议不要写死在本机路径下，而是使用相对路径加配置文件的方式，否则换一台机器运行部署图片全挂。如果不想单独写入配置文件，也可以用系统属性获取当前项目路径，再拼接一个upload子目录。开发阶段图省事怎么都行，但论文里写部署环境的时候，最好描述成"支持将上传文件保存至服务器指定目录，并通过静态资源映射访问"，这个说法专业很多。
另外建议大家开发前就把接口文档写好，哪怕只是一个简单的Markdown页面，把每个接口的地址、请求参数、响应示例列清楚。写文档看起来很费时间，但是前后端联调的时候收益巨大。实际做一个项目，前后端接口对接出现扯皮是很常见的事情，有了文档，至少能快速确认是哪个环节的问题。
7. 写在最后的个人体会
我自己做这个项目的时候，最大的体会是：框架本身真的不复杂，但把一条完整的业务链路理清楚，才是真正花时间的地方。很多代码网上都能找到参考，但宠物购买管理系统这种带交易属性的系统，核心是数据和状态。只要把宠物、用户、订单这三张表之间的关系吃透，把订单状态的流转逻辑理顺，整个项目无论怎么写都不会跑偏。
最后分享一个小技巧：大家做完项目之后，不要急着写论文，先把自己的代码按包结构和模块画一张简单的功能架构图，再把每个核心流程对应到代码里面的路径，比如用户下单的请求从哪里来、经过哪些类、调用了哪些方法，都标注出来。做完这件事，你会发现自己对项目的理解明显加深了一层，写论文的速度也会快很多。
答辩的时候，老师问你某个功能怎么实现的，你如果能从数据库表开始，讲到Controller、Service、Mapper、前端Vue组件，一条链路完整说明白，就已经比大多数同学的完成度都高了。祝各位顺利做完毕设，顺利答辩。
