最近一直在帮学弟学妹们看毕业设计选题，发现一个很有意思的现象：几乎每个Java方向的人都在找“SpringBoot二手商品商城平台毕设源码”这种类型的项目。原因不难理解，交易类系统业务链路完整、技术点覆盖全、演示效果好，尤其二手商城还带点“电商+社区”的味道，比普通的管理系统更能撑起一篇论文。
但我得先说句大实话：网上这类源码一抓一大把，真正能让你顺利跑起来、拿得出手、扛得住答辩的并不多。很多项目下载下来要么缺配置，要么版本对不上，要么代码写得像“堆零件”，压根讲不清楚。这篇我就拿这类项目作为例子，把拿到源码之后该怎么看、怎么改、怎么应付答辩这件事一次盘清楚，顺便把二次开发里容易踩的坑也连带说掉。
1. 项目整体认知：二手商城到底是个什么“毕设”
1.1 一个标题背后的技术栈与业务范围
“SpringBoot二手商品商城平台”这几个字看着普通，背后其实是一整套非常标准的Java Web全栈方案。技术栈基本可以锁定为：SpringBoot做后端主框架，MyBatis或MyBatis-Plus做数据持久层，MySQL存业务数据，Redis缓存登录状态和热点数据，前端要么是Vue + Element UI这类前后端分离方案，要么是Thymeleaf模板引擎做服务端渲染。
业务范围则分成两条线：用户端和管理端。用户端覆盖注册登录、商品浏览、商品发布、搜索筛选、收藏、加入购物车、下单、模拟支付、订单管理、个人中心；管理端覆盖用户管理、商品审核、分类管理、订单管理、数据统计。有些做得细的还会加上举报处理、留言反馈、商品上下架自动定时等。
这里要提醒一点：拿到的源码未必包含上述所有功能。以我的经验来看，二手商城毕设源码的质量差距极大，有的用户端、管理端、数据库脚本一应俱全，有的则只给了后端接口和几张表。所以你第一步不是急着启动，而是先把项目结构看明白，确认功能边界，避免后面才发现缺了模块，搞得手忙脚乱。
1.2 为什么选它：二手商城的毕设优势
二手商城在毕业设计里属于“进可攻退可守”的选题。论技术，它足够覆盖SpringBoot的核心知识点：Spring MVC的请求处理流程、MyBatis的动态SQL、Spring事务管理、拦截器与过滤器、文件上传、JWT或Session登录态管理、Redis缓存、定时任务。这些点随便挑三五个展开，论文的技术部分就不会空。
论业务，二手商城比普通商品管理系统更有故事可讲。比如“闲置物品流通”“环保循环再利用”“校园二手交易场景”这些切入点，既贴近生活又容易写出需求分析。对比那种“某某信息管理系统”，二手商城的业务场景更丰富，图表、用例图、时序图画起来也更顺手。
论演示效果，二手商城的用户操作链路天然适合现场演示。从注册登录、发布商品，到搜商品、加购物车、下单、支付，再到卖家发货、买家确认收货、互相评价，整条链路走下来非常有“完整产品”的感觉。答辩时老师一看你做的不是“增删改查博物馆”，印象分就会上去不少。
1.3 拿到源码后先别急着跑，先确定三种使用方式
很多同学把源码下载下来第一件事就是双击运行，然后被各种报错劝退。其实正确的打开方式是先想清楚“我打算怎么用它”。
第一种是纯借壳型：代码基本不动，把项目跑通，换掉名字、Logo、颜色，补一些自己的界面截图和测试数据，论文按自己的话重写。这种方式最省力，但答辩风险也最高，因为老师一旦深挖代码细节，你很可能答不上来。我不建议纯借壳，但如果时间只剩一周，也只能这么办，前提是你至少要把项目里每个模块的作用搞清楚。
第二种是二次开发型：底子用别人的，核心业务逻辑自己重写或大改，比如把单角色商城改成买家和卖家分离的双角色商城，把普通商品列表改成带条件筛选的闲鱼风格，把静态图片上传改成对接云存储。这样既有现成的地基，又能体现你的独立工作量，是我最推荐的做法。
第三种是重构型：只参考别人的表结构和页面设计，后端代码从头写。这个对基础要求高，时间成本也大，适合那些本来就想靠毕设提升实战能力的人。无论选哪种，你都得先把这个项目“吃透”，而吃透的第一步就是看结构。
2. 源码层面最该先看懂的五张“底牌”
2.1 数据库设计是项目的灵魂，先看表关系
拿到源码后，我强烈建议你把SQL脚本先打开，把表之间的关系理清楚。一个规范的二手商城数据库，通常至少有这些表：用户表、商品分类表、商品表、商品图片表、购物车表、收藏表、订单表、订单项表、收货地址表、评论表，以及管理端相关的管理员表和操作日志表。
商品表是核心，字段一般包含商品名称、描述、原价、转让价、成色（全新/几乎全新/轻微使用痕迹/明显使用痕迹）、所在城市或校区、交易方式（自提/邮寄）、状态（在售/下架/已售出/审核中）、浏览量、发布时间。跟普通商城表不一样，二手商品多了“成色”和“交易方式”这两个关键字段，因为它们直接影响用户的购买决策，也会直接影响前端筛选逻辑。
表关系这块，我建议你画一张简单的关系图：用户和订单是一对多，订单和订单项是一对多，商品和图片是一对多，商品和收藏是一对多。订单表和订单项表拆开的原因是同一个订单里可能包含多个商品，拆开以后统计和退款都好处理。画完这张图，你再看后端代码，很多逻辑就通了。
2.2 用户端功能链路应该能串成一条线
用户端的核心链路并不复杂：注册登录后，从分类或搜索进入商品列表，点进详情看商品信息，然后有两种路径，一种是直接购买走下单流程，另一种是先加入购物车再去结算。下单时填写或选择收货地址，生成订单，模拟支付，支付完成后订单状态变为待发货。卖家发货后状态变为待收货，买家确认收货后状态变为已完成，这时才能对交易发表评价。
这里有一个二手商城特有的逻辑容易被人忽略：一个商品被下单后，应该立刻从“在售”变成“已锁定”或“已售出”，否则会被第二个人重复下单。好的项目会在商品状态和订单状态之间做联动，比如下单成功后就同步更新商品状态，同时用事务保证一致性。如果拿到的源码没有这个设计，建议你二次开发时一定要加上，这个点答辩时讲出来非常加分。
前端页面通常包括首页、分类页、商品详情页、购物车页、订单确认页、个人中心页。如果你拿到的源码是Vue项目，页面代码在src/views目录下，路由配置在router目录下；如果是Thymeleaf版本，页面就在templates目录里按模块分好。先按页面走一遍流程，再去对应Controller里找接口，效率会高很多。
2.3 后台管理没你想的那么简单
管理端是很多人容易忽视的部分，但我要说，它在毕设里占比很大。后台管理主要做什么？第一是商品审核，因为二手平台如果什么商品都能直接上架，很容易出现违规内容，所以正规设计里会有一个“审核通过/驳回”的流程；第二是用户管理，管理员可以禁用违规账号；第三是分类管理，维护商品类目；第四是订单管理，能看到全平台的订单状态并做处理。
如果你拿到的源码里管理端功能很弱，只有简单的用户列表和订单列表，那我的建议是优先补“商品审核”这个功能，原因是它在业务上最说得通，在技术上又能体现你有状态流转的设计意识。具体做法是在商品表加一个audit_status字段，0待审核、1通过、2驳回，管理端提供审核接口，用户端只展示审核通过的商品，改动量不大，但效果立竿见影。
另外，管理端和管理员的登录方式应该跟用户端分开，通常是后台单独登录入口，使用独立的Admin表和管理员Token。如果源码里管理端和用户端共用一个登录接口，你要注意看权限校验是怎么做的，防止普通用户通过改URL直接访问管理员接口。
2.4 商品发布到订单完成，整个流程要能讲清楚
毕设答辩最容易被问的一个问题就是：“你这个系统的核心业务流程是什么样的？”这句话翻译过来就是，你能不能让老师听懂一个商品从发出来到交易完成的完整生命周期。
完整流程是：用户登录后，在“发布商品”页面填写商品名称、描述、价格、成色、图片等信息，提交后商品处于“待审核”状态；管理员审核通过后，商品才在商城前台展示；买家看到商品后发起购买或加入购物车，这时系统要检查商品状态是否为“在售”；订单创建成功后，商品状态变为“已锁定”，避免重复购买；买家支付后订单状态变为“待发货”；卖家在“我卖出的”列表里看到订单，点击发货，订单变“待收货”；买家确认收货后订单变“已完成”；此时双方可以互相评价。
这个流程里，订单状态、商品状态、支付状态三套状态字段很多人会搞混。我的建议是不要把状态全部揉在一个字段里，而是拆开维护。订单用order_status表示（0待付款、1待发货、2待收货、3已完成、4已取消），支付用pay_status表示（0未支付、1已支付），商品用status表示（0待审核、1在售、2已锁定、3已售出、4下架）。虽然字段多了，但逻辑清楚，改起来也安全，不会出现“订单取消后商品不知道去哪了”这种问题。
2.5 权限与安全设计必须单独看
很多毕设源码在权限这块写得很随意，比如只判断“用户是否登录”，却不区分角色。一个合格的二手商城必须有角色区分：普通用户能操作自己的商品、自己的订单，管理员能操作全平台的商品、用户和订单。实现方式通常是用拦截器或Spring Security拦截请求路径，比如/user/**开头的必须是普通用户，/admin/**开头的必须是管理员。
密码安全也是一个容易露怯的点。明文存密码的项目赶紧放弃，合格的方案是使用BCrypt加密，也就是Spring Security里自带的BCryptPasswordEncoder。如果你拿到的源码用的是MD5加盐，其实也能接受，只要不是明文就行，但我建议你在论文里说明你用了加盐哈希，并且密码在数据库中不以明文存储。
登录态这块，现在主流方案是JWT。JWT的好处是后端不用存Session，客户端每次请求带上Token，后端通过拦截器校验即可。看源码时重点看它的拦截器实现，是不是对不需要登录的接口（比如首页列表、商品详情）放行，是不是对需要登录的接口做了Token校验。这个实现细节，几乎是答辩必问区，一定要看懂。
3. 从源码到跑起来：完整实操与参数调整
3.1 环境准备与版本对应关系
先解决“跑不起来”这个最大的问题。以目前最常见的组合为例，SpringBoot 2.7.18配JDK 8是最稳妥的，不要一上来就追新。SpringBoot 3.x要求JDK 17，很多同学的电脑上默认只有JDK 8，直接用3.x版本就会报错，这就是为什么网上总有人在问“springboot版本太高怎么办”。
如果你拿到的源码是SpringBoot 2.x，那么环境建议是：JDK 8、Maven 3.6以上、MySQL 5.7或8.0、Redis 6.x。如果是SpringBoot 3.x，那就用JDK 17。这里有个小技巧：看pom.xml里的spring-boot-starter-parent版本号，2.x还是3.x一眼就知道，不用去猜。
数据库版本也很关键。MySQL 8.0和5.7在连接驱动、时区处理上有区别，如果你用的是MySQL 8.0，驱动应该是com.mysql.cj.jdbc.Driver，连接URL里要加serverTimezone=Asia/Shanghai，否则控制台会报时区错误。这一条几乎每个跑SpringBoot项目的人都会碰到，属于必踩之坑。
3.2 配置文件里的必改项
项目跑不起来的核心原因，八成出在application.yml或application.properties配置上。拿到源码后，你需要重点检查和修改以下几项。
第一是数据源。spring.datasource.url里面的数据库名、用户名、密码必须改成你本机的实际值。我遇到过很多人把数据库名漏改，导致启动时报“Unknown database”。建库时建议用UTF-8字符集，SQL脚本里如果没写，你就手动执行create database if not exists second_hand default character set utf8mb4。
第二是Redis配置。只要项目依赖了spring-boot-starter-data-redis，启动时就必须要有一个可用的Redis连接，否则项目起不来或登录时报错。本地启动默认是spring.redis.host=localhost，port=6379，密码默认空，如果你本地Redis设置了密码，记得同步改配置。
第三是文件上传路径。商品图片上传到本地后，项目访问图片需要一个映射路径，常见写法是配置一个file.upload-dir和对应的静态资源映射。这个路径在Windows和Linux下写法不一样，建议用相对路径或配置成绝对路径都可以，但注意目录必须存在并且有写权限，否则上传功能会失败。
第四是端口。如果8080端口被占用，把server.port改成8081或9090即可，但改完记得前端调接口的地址也要跟着改，如果是前后端分离项目，前端一般在.env.development文件里配了VUE_APP_BASE_URL。
3.3 初始化数据的两个关键点
首次运行项目前，一定要先执行SQL脚本。这里有两个关键点容易踩坑。
第一，SQL脚本的导入顺序。如果一个脚本文件里包含了建库、建表、插入测试数据，直接导入即可；如果分成多个脚本，就先跑表结构，再跑数据。有些脚本开头有use database名，有些没有，没有的话你在Navicat里选中对应的数据库再执行。
第二，注意初始管理员账号。绝大多数项目会在SQL里预置一个admin账号，比如用户名admin，密码admin123，密码是经过加密的。如果你在登录页试了默认账号密码却登不进去，可以先看SQL里预置的数据，再在代码里搜索加密逻辑，判断默认密码到底是什么。这个信息直接决定了你能不能进后台。
还有一个细节：测试数据里如果包含图片路径，而这些图片在你本地不存在，那商品列表会显示裂图。我可以接受这一点，不影响功能演示，但如果你要交作业或截图，建议自己传几张图，重新走一遍发布流程。这样生成的数据库数据也更有“你自己操作过”的说服力。
3.4 本地跑通后的验收清单
项目能启动不等于项目没问题，我建议你按下面这张清单逐项验收，把发现的Bug记录下来，这些记录还可以写进论文的“系统测试”章节，简直是现成的素材。
- 注册一个新用户，确认密码不是明文存库。
- 用新用户登录，修改个人资料，退出后重新登录确认状态保持。
- 发布一个商品，上传图片，确认图片能正常显示。
- 管理员账号登录后台，审核刚才发布的商品。
- 回到用户端，确认商品出现在列表里，详情页正常。
- 搜索一个关键词，确认搜索结果准确。
- 把商品加入购物车，然后下单，确认订单生成且商品状态变为已锁定。
- 模拟支付，确认订单状态变化。
- 在“我卖出的”列表里发货，在“我买到的”列表里确认收货。
- 对订单进行评价，确认评价展示在商品评论区。
整个流程走完，你基本就能回答“用户怎么用你这个系统”这个问题了。遇到哪个环节报错，不要慌，第5部分我会专门讲这些问题怎么排查。
4. 把“别人的源码”变成“你的毕设”
4.1 二次开发优先级排序
如果你有时间改代码，我建议按下面的优先级来排序，投入产出比最高。
第一优先：把单角色商城改成买家/卖家分离的双角色模式。这是闲鱼、转转这类二手平台的核心设计，也是普通商城毕设里少见的亮点。改动思路很简单：用户表加一个role字段（0普通用户、1卖家），发布商品时指定当前登录用户为卖家；商品详情页显示“联系卖家”入口，订单列表区分“我买到的”和“我卖出的”；卖家只能操作自己发布的商品和对应的订单。这个改动涉及表设计、接口权限、前端页面三个层面，工作量适中，但讲出来的时候复杂度一下子就不一样了。
第二优先：增加商品筛选和排序功能。二手商品最典型的需求是按成色筛选、按价格区间筛选、按最新发布排序、按价格排序。前端加几个下拉框，后端在SQL层面加动态条件即可。用MyBatis-Plus的话，QueryWrapper里直接condition判断参数是否为空，非常方便；用XML的话就写动态SQL。这个小功能能体现你对用户需求的理解，而且开发成本极低。
第三优先：热度数据展示。在管理端加一个简单的统计面板，展示注册用户数、商品总数、今日订单数、交易总额。用SQL的count、sum、groupBy就能实现，图表可以集成一个轻量的ECharts，不用做得很复杂，柱状图加折线图就够。数据统计是论文里“系统特色”部分的常客，建议加上。
4.2 答辩时教授最可能问的几个点
答辩最怕的不是答错，而是完全没准备。根据我的经验，老师拿着二手商城项目的源码，翻来覆去问的无非就是下面这几个问题。
第一个问题是“JWT的原理是什么”。你要能说清楚三部分：Header、Payload、Signature。Header里是加密算法，Payload里是用户信息，Signature是签名，服务端用密钥对前两部分签名，客户端每次请求带上Token，服务端验签通过就认为用户已登录。JWT解决了Session在分布式环境下共享难的问题。
第二个问题是“为什么用Redis”。常见回答是缓存热点数据和存储登录Token。缓存商品列表可以减轻数据库压力，用Redis存Token可以实现多端会话管理。如果你还用了Redis做验证码存储或短信验证码，那就可以说明Redis的过期时间特性如何派上用场。
第三个问题是“分页是怎么实现的”。后端常见方案是PageHelper或MyBatis-Plus的分页插件。你要能说清楚前端传pageNum和pageSize，后端构造Page对象，查询时自动拼接LIMIT语句，最后返回总条数和当前页数据。如果手写分页，那就是LIMIT offset, size，offset等于(pageNum-1)*pageSize。
第四个问题是“事务在哪里用到了”。标准答案是下单操作：创建订单、扣减商品状态、清空购物车这三个步骤必须在同一个事务里，否则用户下单成功后商品状态没变，就会出现超卖问题。你可以把下单方法上的@Transactional注解指给老师看，然后解释事务的ACID特性。
第五个问题是“不同角色的权限怎么控制的”。回答核心是拦截器或过滤器：登录拦截器校验Token，RoleInterceptor判断当前用户角色，如果访问的是管理员接口但角色是普通用户就直接拒绝。如果用了Spring Security，就说是通过配置SecurityFilterChain，对不同的路径做hasRole判断。
4.3 时间规划：一周突击还是两个月精改
说到时间安排，我见过太多前松后紧的案例，所以这里把两种方案的时间分配都写出来。
如果你只剩一周，方案是全速跑通加局部改动。前1天用来配置环境和导入数据库，务必让项目跑起来。第2天把用户端完整走一遍，第3天把管理端走一遍，第4天集中在两个点做改动，比如加一个筛选功能和做一个数据统计页面。第5到第7天用来写论文、截图、准备答辩PPT和演练讲稿。这个方案的底线是：你能完整演示，并且对改过的代码能讲清楚。
如果你有三个月，方案是前一个月吃透源码，第二个月做二次开发，第三个月写论文和打磨演示。第一周只看数据库和登录模块，第二周看商品模块，第三周看订单模块，第四周看管理端。不建议一口吃成胖子，按模块推进，每看完一个模块就写一段笔记，这些笔记后面可以直接变成论文的设计与实现部分。
不管时间多少，我都强烈建议把每天的进展记录下来，哪怕是简单的一句话“今天看懂了商品发布流程，表结构涉及product和product_image”，积累半个月后你会发现自己对项目的理解有了质的提升。
4.4 论文与源码的对应关系
写论文时，最容易被老师挑战的就是“代码和论文对不上”。其实论文里真正需要重点写的就是三条线。
第一条线是需求分析。用户端、卖家端、管理员端各有哪些需求，用用例图表达。网上有很多模板，但别直接抄，把你项目里真实存在的功能画上去。比如有商品审核就有“审核商品”这个用例，没有的话就别画，老师一旦提问就会露馅。
第二条线是系统设计。根据数据库表结构画出ER图，写清楚每张表的字段和用途；画系统架构图，描述从上到下依次是浏览器、Controller、Service、Mapper、MySQL和Redis；画时序图描述下单流程。这一部分的目标是让老师觉得你设计过系统，而不是糊弄出来的。
第三条线是系统实现。每个核心模块选一个关键点来写：商品模块讲动态SQL分页搜索，订单模块讲事务控制，登录模块讲JWT校验，文件上传讲文件存储和访问映射。每个点附上核心代码和运行截图，说明“效果怎么样”，不要光贴几百行代码。
论文的测试部分也可以利用你前面验收清单里记录的情况来写，功能测试用例和结果一一对应，这就是最真实的测试报告。
5. 常见问题与排查实录
5.1 启动失败类
项目启动直接报错，最常见的三类原因：端口占用、依赖下载失败、数据库连接不上。
端口占用好解决，报错信息里有Port already in use字样，换端口或杀掉占用进程就行。依赖下载失败一般出现在Maven库不完整或网络不稳定的情况下，我的建议是把本地仓库，也就是默认在用户目录下的.m2/repository里的相关文件夹删掉，然后在IDEA里点一下Maven的Reload，让它重新下载。公司网络如果有限制，可以考虑换一个镜像源，将Maven的settings.xml里的mirror配置为阿里云公共仓库。
数据库连接不上的报错一般是Caused by: java.sql.SQLException: Access denied for user。这基本就是用户名密码不对，或者数据库还没建。回到第3.2节，把数据源三项参数逐一核对即可。
5.2 登录鉴权类
登录成功但是访问其他接口一直提示未登录，这个问题的原因十有八九是Token没有传对。前后端分离项目里，前端一般在请求拦截器里从localStorage里取出Token，放到Header的Authorization字段；后端的拦截器再从Header里取Token做校验。如果前端代码和后端的Header名称对不上，比如前端放的是token，后端取的是Authorization，那自然就一直未登录。
还有一种情况是Token过期时间太短，比如设置成5分钟，演示到一半就过期了。建议把过期时间设置成24小时以上，毕设而已，没必要搞严格的安全策略，方便演示最重要。
另外一个坑是Swagger测试接口时没有配置Token。如果你集成了Knife4j或Swagger，需要设置全局Token参数，否则在Swagger里调试需要登录的接口也会一直报未登录。
5.3 图片上传类
图片上传功能报错比较多的场景是路径不存在或者访问404。上传成功但访问不到图片，要看文件真实存放在哪里以及静态资源映射路径是否匹配。前端显示图片的URL是upload/20250101/xxx.jpg，那么后端配置的addResourceHandlers就要把/upload/**映射到磁盘上的真实目录。
如果你改了文件上传目录，一定要记得重启项目再测试，因为静态资源映射的配置在启动时加载，改了不重启不会生效。此外，上传的文件名如果有中文或特殊字符，建议让后端统一用UUID重命名，否则在不同浏览器里可能显示异常。
5.4 分页与搜索类
分页数据总是不对，先检查前端传的参数名和后端接收的参数名是否一致。前端传pageNum和pageSize，后端的Controller入参也必须是这个命名，或者加@RequestParam指定参数名。用PageHelper时还要注意分页插件必须写在查询语句之前，而且同一个线程里连续执行两条查询，分页参数可能会串，所以不要在startPage和PageHelper.clearPage之间执行无关查询。
搜索功能查不出数据，重点排查SQL条件，尤其是模糊查询的写法。MyBatis的XML里用concat('%', #{keyword}, '%')，别直接在SQL里写%keyword%，那是字符串拼接，会有SQL注入风险。如果你改成了参数化查询，记得测试中文搜索是否正常，连接数据库的URL里带上characterEncoding=utf8，中文乱码问题就少很多。
5.5 数据库乱码与时区问题
数据插入中文后变成问号，这是非常典型的编码问题。首先保证建库时用了utf8mb4，其次保证连接URL里带了useUnicode=true和characterEncoding=utf8，最后保证前端页面或接口传的本身就是UTF-8编码。三点都做到，乱码问题基本消掉。
时区问题的一般表现是数据库里的时间比当前时间早8小时或晚8小时。解决方法是在连接URL里加上serverTimezone=Asia/Shanghai，如果还不行，就去检查MySQL服务端的时区设置，执行SQL命令SET GLOBAL time_zone = '+8:00'，或者修改my.cnf里的default-time-zone。Java层面最好统一用LocalDateTime来处理时间，避免Date在打印或返回JSON时出现偏移。
我自己的习惯是在项目里写一个全局的时间格式化配置，统一JSON序列化时的日期格式为yyyy-MM-dd HH:mm:ss，这样前端拿到的数据格式统一，省去很多跟时间有关的奇怪Bug。代码大概是这样：
@Configuration public class JacksonConfig { @Bean public Jackson2ObjectMapperBuilderCustomizer jsonCustomizer() { return builder -> builder.simpleDateFormat("yyyy-MM-dd HH:mm:ss") .serializers(new LocalDateTimeSerializer(DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss"))) .deserializers(new LocalDateTimeDeserializer(DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss"))); } }这套配置放在config包下，项目启动时自动生效，不算复杂，但对体验的提升非常明显。
最后再分享一个小经验：不管你是用什么方式拿到这份“SpringBoot二手商品商城平台毕设源码”，都不要急着改代码。先把SQL脚本里的每一张表、每一个字段用表格整理出来，形成一张“字段地图”，再顺着地图去读Controller层接口。这样做看起来慢，但后面改代码、写论文、答辩回答问题都会特别顺，因为这相当于你把整个项目的骨架装进了自己脑子里。真正动手做的时候你会发现，毕设拼的不只是代码能力，更是你吃透一个系统的耐心。
