Springboot计算机毕业设计网上图书商城这套题目这些年几乎年年都会出现在毕设选题清单里。别人一听“图书商城”觉得普通但真正做过的都知道它麻雀虽小五脏俱全用户、商品、购物车、订单、后台管理电商系统该有的核心链路它全涉及了而且用Springboot做底层既能体现框架能力又不会把自己逼到微服务那种大坑里。这篇东西就是冲着毕设场景来的适合Java方向、需要独立完成全栈项目的同学也适合课程设计想拿个像样题目的朋友。我接下来把功能拆解、数据库设计、后端实现、环境搭建、调试部署、论文写作这几个环节全部过一遍每一块都按实际开发时的思路来讲怎么踩坑怎么补窟窿直接照着做就能把项目跑起来。1. 项目整体拆解图书商城到底在做什么1.1 为什么图书商城是毕业设计的“安全牌”先说说选这个题目的逻辑。做毕设最怕什么怕题目太偏查不到资料、模板少、技术栈冷门最后卡在某个环节折腾半个月。图书商城属于标准的电商业务系统写技术文档的人多遇到问题能搜到的解决方案也多这是最直接的“安全感”。从技术角度看图书商城覆盖了Java Web开发的核心知识点。SSM时代的Session登录、购物车逻辑Springboot时代的自动配置、starter依赖管理还有MyBatis的SQL映射、MySQL的事务处理这些全是面试也会问的东西。把它做完相当于把大学四年学的那套东西串了一遍。从答辩角度看图书商城功能肉眼可见。评委看你演示的时候图书列表、加入购物车、下订单、后台发货、统计销量每一步都有明确的操作反馈比那种“智能分析系统”只有一堆看不明白的图表直观得多。演示流畅答辩就赢了一半。从扩展角度看这个题目能深能浅。基础版就做增删改查加购物车订单想拿高分就在用户权限、订单状态机、事务一致性、数据统计这些方向上加料。技术深度是能自己控制的不像一些冷门方向想深挖都找不到切入点。1.2 功能模块拆解前台展示与后台管理一条链图书商城的功能模型本质上就是两套界面一套数据库。前台面向普通用户后台面向管理员业务上通过同一套订单数据打通。前台模块我建议这样划分用户模块注册、登录、个人信息维护、收货地址管理图书模块图书列表、按分类筛选、按关键词搜索、图书详情购物车模块加入购物车、修改数量、删除选中项、合计金额订单模块结算生成订单、订单列表、订单详情、取消订单其他首页轮播图、推荐位、系统公告后台模块逻辑上独立功能更重管理管理员登录与权限拦截图书管理上架、编辑、下架、库存修改、封面图上传分类管理增删改查前台联动订单管理订单列表、发货操作、查看详情用户管理查看注册用户列表、禁用/启用账号数据统计订单总数、销售额、热门图书排行功能列表单看不觉得多但每一块背后都有技术点。权限拦截用拦截器或过滤器图片上传用MultipartFile加本地存储订单生成要考虑事务和并发数据统计要写聚合查询SQL。功能与功能的组合才是这个项目的真正价值。1.3 技术栈选型为什么是SpringbootMyBatisMySQL毕设技术栈的选择核心原则就六个字够用、稳妥、能讲。Springboot、MyBatis、MySQL这三件套是Java毕设里最经典的组合。Springboot解决的是配置地狱问题。以前用SSM框架光是spring-mvc.xml、mybatis-config.xml这些配置文件就能让新手怀疑人生。Springboot靠自动配置和starter把大部分样板配置干掉application.yml几十行配置就能把项目跑起来。毕设时间有限省下的时间应该花在业务逻辑上而不是跟XML配置文件较劲。MyBatis作为持久层框架优点是SQL自己控制可读性强。图书商城的SQL并不复杂但像“联表查订单明细”“按条件动态搜索图书”这类需求MyBatis的注解和动态SQL处理起来非常顺手。而且MyBatis在国内企业中的使用率一直很高答辩官也不会质疑你的选型。MySQL是标配不需要多解释。唯一要提醒的是装MySQL尽量用5.7或8.0版本太老的5.5版本对utf8mb4字符集支持不好项目里用到表情符号或特殊字符可能报错。前端这块基础做法是服务端渲染Springboot模板引擎用Thymeleaf或者直接放静态HTML页面加Ajax调用接口。如果自己前端基础还可以也可以做前后端分离Vue写页面Springboot只提供Restful接口。两种方案都行我的建议是按自己水平来不要为了显得高级硬切前后端分离最后联调阶段把自己坑进去。补充一个技术点很多人忘了Springboot自带Spring Security但毕设项目用它的成本较高配置复杂、门槛高。搞个登录拦截器加Session判断就够用了好实现答辩也好解释。2. 数据库设计地基层次决定项目上限2.1 整体表结构规划做图书商城数据库设计之前先想清楚业务上有哪几个核心实体用户、图书、分类、购物车项、订单、订单明细、地址。顺着这个思路数据库表数量大约在7到10张之间属于中等规模既撑得起论文篇幅又不会多到看不过来。我设计的标准表结构如下user用户表含账号密码、昵称、联系方式、注册时间、角色标识category图书分类表含分类名称、排序值book图书表含书名、作者、出版社、ISBN、原价、售价、封面图、库存、销量、上下架状态、分类外键cart购物车表含用户外键、图书外键、购买数量orders订单表含订单号、用户外键、收货信息、总金额、状态、下单时间、支付时间、发货时间order_item订单明细表含订单外键、图书外键、图书快照信息名称、价格、封面、购买数量address收货地址表含用户外键、收件人、电话、详细地址、默认标识在这之上可以根据需要加表比如公告表notice、轮播图表banner。但核心就是上面这7张先把主干立住再谈枝叶。设计时有个容易忽略的点订单明细表为什么要冗余图书名称和价格因为图书表里的价格会变用户下单后如果管理员改价订单明细里的金额不能跟着变。订单是历史事实必须用快照的方式把下单那一刻的商品信息固定下来。这个细节写进论文里能看出你在数据一致性上动过脑子。2.2 核心表字段设计详解图书表book是核心业务表字段设计直接影响前台页面能否正常展示。以下是建议的最小字段集字段名类型说明idint/bigint主键自增book_namevarchar(100)书名authorvarchar(50)作者publishervarchar(50)出版社isbnvarchar(20)国际标准书号pricedecimal(10,2)售价original_pricedecimal(10,2)原价用于展示折扣covervarchar(255)封面图URLstockint库存salesint销量statustinyint0下架 1上架category_idint分类外键descriptiontext图书简介create_timedatetime创建时间这里两个细节值得注意。价格字段务必用decimal不能用float或double后者有精度问题电商项目的钱相关字段是硬编码要求踩了这个坑答辩会被追问。库存和销量适用于程序设计为int但在下单逻辑里要有库存校验防止买到负数。status字段作为上架/下架开关前台查询时必须带上status1的条件很多新手忘了这茬下架的书还在前台展示。订单表orders的字段设计同样关键字段名类型说明idbigint主键order_novarchar(32)订单号业务唯一user_idint下单用户total_pricedecimal(10,2)订单总金额statustinyint0待付款 1待发货 2待收货 3已完成 4已取消receiver_namevarchar(50)收件人receiver_phonevarchar(20)收件电话receiver_addressvarchar(255)收件地址create_timedatetime下单时间pay_timedatetime支付时间delivery_timedatetime发货时间订单号的生成也是个小考点。不要用数据库自增id当订单号那样太容易猜测业务量。常规做法是时间戳加随机数或者用年月日时分秒加用户id再加随机数。格式无所谓核心是唯一性。后续做“生成订单号”的工具类时记得加并发保护多用户同时下单不能生成重复号。2.3 订单状态流转的逻辑订单状态是整个项目中逻辑最复杂的部分也是答辩时最容易被追问的内容。原因很简单状态字段不只是存个数字它背后有业务规则。我定义的状态机是这样0 待付款用户提交订单后默认状态此时可以取消订单库存已经预占1 待发货模拟支付成功此时管理员在后台能看到并进入发货操作2 待收货管理员点击发货后到达此时用户可以在前台看到物流信息或知道已发货3 已完成用户确认收货此订单走完流程4 已取消用户主动取消或超时未支付取消状态流转就是一条线0到1是用户支付1到2是管理员发货2到3是用户确认。任何非法跳转都要在前端和后端同时拦截。前端控制按钮显隐后端在修改状态时校验前置状态比如只有status2的订单才能被改成3否则直接拒绝。还有一个细节用户取消订单后库存要加回去。这个动作必须在同一个事务里完成否则会出现“订单取消了但库存没恢复”的脏数据。我当时第一次做的时候忘了这一点测试时连续下几次单再取消库存越变越小后来调试了半天才发现是库存回补逻辑漏了。这个点写进论文测试章节是实打实的测试发现缺陷案例。3. 后端核心实现把每个模块做扎实3.1 项目分层结构与关键依赖拿到一个Springboot项目源码第一步不是急着跑而是先把目录结构读一遍。标准的工程结构分四层从下往上依次是entity实体类、mapper数据访问层、service业务逻辑层、controller控制层。实体类对应数据库表字段mapper接口定义SQL操作service处理业务规则controller接收前端请求并返回数据。有人会问这么分层不累吗小项目必须这样吗答案是必须维护。图书商城的购物车结算逻辑涉及多张表的读写如果在controller里直接写mapper调用代码会很快变得不可维护。分层之后controller只做参数接收与响应封装业务都沉淀在service里出了问题能快速定位这个也可以在论文里作为系统设计的亮点去写。pom.xml里的关键依赖要捋清楚spring-boot-starter-webWeb应用核心内置Tomcatmybatis-spring-boot-starterMyBatis整合starter注意版本要和Springboot版本匹配mysql-connector-javaMySQL驱动8.0.x驱动对应较高的Springboot版本lombok简化实体类代码自动生成getter/setter模板引擎依赖选了Thymeleaf就加thymeleaf相关starter选了前后端分离就加spring-boot-starter-validation等工具依赖有个依赖管理的小技巧Springboot的spring-boot-starter-parent已经帮你锁定了大部分依赖版本自己额外引入的依赖尽量不要随意写版本号避免版本冲突。MyBatis的starter版本最好和官方文档推荐保持一致我用的是mybatis-spring-boot-starter 2.x系列配合Springboot 2.x跑得很稳。3.2 用户登录与权限控制怎么做图书商城的权限模型很简单普通用户和管理员两套角色。前台页面所有人可看但加入购物车、下订单必须登录后台管理页面只有管理员能进。登录状态的管理有三种常见方案Session方案登录成功后把用户信息放进session拦截器判断session是否存在。实现简单符合毕设体量缺点是分布式环境下session共享困难不过毕设不存在分布式的场景。Token方案登录成功后签发一个token可以用JWT前端每次请求带在请求头里后端拦截器解析校验。实现稍复杂但更接近企业内部项目的做法。Spring Security方案功能强大但配置复杂对毕设来说属于重武器不推荐。我推荐用Session加拦截器的组合理由是好讲、好理解、不会在答辩时被追问到答不上来。核心逻辑是写一个LoginInterceptor实现HandlerInterceptor接口在preHandle里检查session中的用户对象没有就重定向到登录页或返回未登录状态码。然后在配置类里注册拦截器排除掉登录、注册、图书列表、图书详情等无需登录的路径剩下的全部拦截。密码存储必须用MD5加盐或BCrypt绝不能明文存储。曾经见过有的毕设源码里密码直接明文进库这是安全大忌。用Spring自带的DigestUtils.md5DigestAsHex对密码加盐后存储代码几行就搞定。答辩问起来你回答“防止彩虹表破解、加盐提高存储安全性”这就是一个加分的细节。3.3 购物车、下单与事务处理的实现要点购物车的实现有两种思路。存在Session里缺点是换设备就丢而且购物车数据跟用户没法绑定存在数据库里每个用户一行数据对应一本图书数量和关联关系都在服务端体验更好。图书商城作为毕设建议直接做数据库版购物车表结构已经规划好了查询和更新都很简单。加入购物车的SQL逻辑是核心。先按用户id和图书id去查购物车表如果记录存在就执行数量加一update不存在就插入一条新记录insert。这种做法叫upsert虽然用两条SQL也能实现但写成动态SQL更优雅也减少一次数据库的交互。很多同学在这里图省事直接插入结果同一本书在购物车里出现两行结算时还得去重就是给自己挖坑。下单逻辑是整个项目最复杂的地方必须用事务包裹。一个完整的下单流程包含以下步骤查询出购物车中选中的项或全部逐项校验图书状态和库存计算订单总金额生成订单主记录状态为待付款生成订单明细快照记录扣减图书库存、累加图书销量清空对应用户的购物车记录任何一个步骤失败前面所有步骤都要回滚。具体到代码就是在service方法上加Transactional注解同时注意同一类内部方法调用的自调用问题否则事务会失效。答辩时问到“如何保证下单数据一致性”就能把这一整套逻辑讲出来。这里再补充一个坑库存校验不能只在应用层做if判断因为并发情况下两个用户同时下单可能都检查到库存充足然后都执行扣减导致库存变负。实际生产项目会用乐观锁或数据库行锁。毕设建议用乐观锁在book表的stock字段上做版本控制或者用update语句中加where stock count的原子条件去扣减。写进论文的话这属于并发控制章节的内容含金量一下就上去了。3.4 文件上传与静态资源路径映射图书封面图是图书商城不可缺少的功能点。实现方式不外乎两种传到服务器本地保存、传到第三方OSS。毕设场景推荐本地保存简单可控不依赖外部服务。关键配置有两处。第一处是在application.yml里设置上传大小限制spring: servlet: multipart: max-file-size: 10MB max-request-size: 10MB第二处是把本地磁盘路径映射成访问URL。比如把封面图存到项目的imagePath目录下然后通过WebMvcConfigurer配置addResourceHandlers把/image/**映射到本地磁盘路径。这样上传成功后生成图片访问地址保存到数据库的cover字段前端直接用img标签访问。遇到过的一个典型问题上传成功但图片加载不了页面404。排查下来发现是没有配置资源映射Spring Security把图片请求拦了或者路径压根没匹配上。记住一句口诀上传是写文件访问是读资源两者要各配各的路径。另外后端一定要对上传文件做类型校验只允许jpg、png等常见图片格式防止有人传可执行文件冒充图片这也是答辩能讲的数十个安全细节之一。4. 环境搭建与调试部署从拿到源码到跑起来4.1 开发环境初始化与版本匹配很多人卡在项目跑不起来的第一个环节就是环境版本不匹配。Springboot项目对JDK版本、Maven版本、数据库版本都有隐性要求。你拿到的源码如果是Springboot 2.7写的大概率对应的JDK是8或11用JDK 17去跑可能会出现编译错误或运行时异常因为你依赖的某些老库不兼容新JDK。我的建议是提前确认三件事JDK版本打开pom.xml看java.version标签一般写1.8就是JDK 8Maven版本3.6.3以上基本够用重点看Maven仓库中的镜像配置国内大环境建议配置阿里云镜像否则下载依赖能等半小时MySQL版本5.7以上无压力8.0需要注意驱动和时区配置IDEA设置里有个容易忽略的点Project Structure中的Project SDK必须和你配置的JDK一致默认Maven设置里的JDK也要统一。很多报错“程序包不存在”其实不是缺依赖而是IDEA编译用的JDK和项目要求的不匹配。环境准备好之后第一步不要急着点运行先执行mvn clean compile确认依赖能下载、代码能编译。编译都过不了的项目想靠配置去救是没可能的。4.2 数据库初始化的正确姿势数据库导入是整套流程里最让人心累的一步因为90%的“项目起不来”都是数据库环节出的问题。你要做的无非是这三件事第一建库。新建一个数据库注意字符集用utf8mb4排序规则用utf8mb4_general_ci或utf8mb4_unicode_ci都行。说过很多次千万别用utf8否则有些生僻字和特殊符号会乱码。第二导表导数据。直接运行项目配套的sql文件里面通常包含建表和初始数据。导入后打开表看一眼如果表全空可能需要你再执行一段初始化数据的SQL或者确认SQL文件本身是否包含insert语句。另外把user表里管理员的密码改成你自己知道的值但这要连带调整代码里的加密逻辑否则一个规则不一致管理员就登录不了。第三核对配置文件。打开application.yml或application.properties确认spring.datasource.url里的数据库名、用户名、密码全部匹配当前环境。这里有一个经典的坑是MySQL 8.0的驱动需要配置时区URL上加上serverTimezoneAsia/Shanghai否则6小时时差问题会让人摸不着头脑。4.3 本地运行调试的几招实用技巧项目第一次启动成功不等于万事大吉。后面的联调过程中有几个调试技巧非常实用。第一个是热更新。Springboot项目在IDEA里修改Java代码后默认需要重启才能生效频繁重启非常影响效率。建议引入spring-boot-devtools依赖并且开启IDEA的Build project automatically实测改完代码按一下CtrlF10就能热更新效率提升非常明显。第二个是日志查看。启动报错时不要只看最后几行要把完整堆栈往上翻。Springboot的报错信息经常很长真正的根因往往在中间位置被“Caused by”几个字引出来。看到“Caused by”就顺着往下追那才是错误的源头。第三个是接口调试工具。如果是前后端分离项目强烈建议装一个接口测试工具Postman或Apifox都行。写好的接口先拿工具测一遍确认返回的数据结构正确再去对前端否则前端页面白屏你都不知道是前端代码问题还是接口问题。4.4 打包部署到服务器的基本流程毕设答辩现场通常要求项目在本地或服务器上演示提前学会打包部署能避免很多突发情况。打包命令很简单mvn clean package -DskipTests执行完会在target目录下生成一个jar包这个包就是可运行的完整程序。本地验证方式是在命令行执行java -jar 项目名.jar注意这里有个小坑当jar包和项目配置的本地图片上传路径不在同一目录时上传的图片可能保存不到预期位置。部署到服务器后路径问题必须重新配置建议用绝对路径不要用相对路径。如果要部署到Linux服务器步骤也不复杂上传jar包到某个目录nohup方式启动nohup java -jar 项目名.jar log.log 21 进阶一点可以用systemd配置成系统服务服务器重启后自动拉起。这一块虽然不是必须但写成论文部署方案或者答辩材料是一个亮点体现你考虑到了实际生产环节。5. 常见问题与排查技巧实录5.1 启动失败端口占用与依赖冲突Springboot项目启动时最常见的报错之一就是“Port 8080 was already in use”。解决办法简单粗暴要么杀掉占用端口的进程要么改项目端口。改端口时注意两处application.yml里改server.port还有前端页面里所有请求的URL如果写了端口号也要同步改。很多前端页面保存的是绝对地址端口一换页面请求全都失败。依赖冲突的典型表现是编译报“NoSuchMethodError”或运行时出现“ClassNotFoundException”。遇到这类问题第一步执行mvn dependency:tree看依赖树找到冲突的依赖用exclusion把不需要的版本排除掉。最常出问题的是各种JSON解析库和日志库Springboot自带了一套自己再引其他库很容易打架。5.2 数据库连接失败的综合排查数据库连不上报错信息五花八门但排查路径是固定的。先用命令行或数据库客户端工具试一下连接确认数据库本身是通的。然后看项目的配置文件和实际环境是否一致包括地址、端口、账号、密码、数据库名。最后检查驱动版本。这里列举几个高频报错和对应的解决办法报错信息关键词原因解决方案Access denied for user用户名或密码错误核对账号密码注意MySQL自带用户root的密码是否设置Communications link failure连接地址端口错误或服务未启动确认3306端口监听用telnet测试连通性Public Key Retrieval is not allowedMySQL 8.0的认证机制问题JDBC URL加allowPublicKeyRetrievaltrueUnknown database配置的数据库名不存在检查URL中的库名确认已建库Server returns invalid timezone时区不匹配URL加serverTimezoneAsia/Shanghai5.3 页面显示异常跟踪思路页面打开白屏、样式乱、请求404或500这类问题在联调阶段几乎天天见。白屏优先看浏览器F12控制台如果是前后端分离项目看“Network”标签里请求的状态码和响应内容。404可能是接口路径写错也可能是后台接口压根没发布。500则是后端代码运行出错打开IDEA控制台看详细堆栈。样式乱通常是静态资源路径问题。页面引用的CSS和JS文件路径是相对路径还是绝对路径项目context-path有没有配置这些都是排查点。如果用Thymeleaf模板注意th:href{/css/style.css}这种写法才是标准姿势手工拼接路径容易出错。5.4 常见问题速查表以下是我实际帮学生跑毕设时遇到频率最高的几个问题全部整理成速查表问题定位方向处理方式图片上传后前端不能预览资源映射配置检查addResourceHandlers路径是否匹配修改商品库存后前台数据不变缓存或页面刷新确认查询是否命中旧数据加缓存时注意失效策略中文乱码编码不统一数据库连接URL加characterEncodingUTF-8检查文件编码注册后登录提示密码错误加密逻辑不一致确认注册和登录用的加密算法/盐完全相同部署到服务器后内网可访问外网不行云服务器安全组登录云控制台开放8080端口数据库中文数据导入报错字符集不匹配重建数据库字符集用utf8mb46. 论文结构与答辩准备最后一公里的加分项6.1 论文结构怎么安排做完了项目和代码论文写作是很多同学头疼的事。图书商城论文的常规结构是这样第一章绪论写研究背景和意义、国内外研究现状、主要研究内容与技术路线。这部分网上模板一大堆但注意不要抄得太明显把技术栈换成Springboot的描述跟自己的功能对应上。第二章相关技术介绍把Springboot、MyBatis、MySQL这几个技术挨个介绍一遍。这章最好写也最容易被评委看出来是凑字数。想加分的做法是加入技术选型的对比分析比如为什么不用SSH而用SSMSpringboot为什么不用NoSQL而用MySQL写清楚利弊。第三章需求分析从用户和管理员两个角色出发画用例图写功能需求和非功能需求。重点写清楚每个角色能做什么操作最好配一张自己画的用例图。第四章系统设计总体架构图、功能模块图、数据库ER图、表结构设计。数据库表记得用表格罗列字段字段名、类型、说明写清楚。第四章是整篇论文的专业度担当必须认真画图、认真排版。第五章系统实现按功能模块逐个描述实现过程。重点是写关键方法的功能与核心代码片段配合运行截图。这章不要光贴代码先写实现思路再放核心代码最后放效果图三步缺一不可。第六章系统测试功能测试用例加测试结果测试数据要有代表性。测试用例表格写清楚测试项、输入数据、预期结果、实际结果、是否通过。再补充一点性能或安全方面的测试比如并发下单的库存校验测试比单纯写“全部通过”更有说服力。论文整体写下来核心逻辑是需求分析引出设计设计对应实现实现验证测试。环环相扣只要每个环节都写清楚论文自然就是一篇合格的毕设论文。6.2 答辩高频问题与应对思路答辩环节评委喜欢问的问题其实就那么几类提前准备就不会慌为什么选Springboot回答要点简化配置、自动装配、生态完善、适合快速开发。最好能顺带提一句Servlet/SSM在配置上的痛点展示你的对比思考。项目里最难的技术点是什么这是一个极具价值的问题因为答完这个你基本就掌握了整场答辩的主动权把评委的兴趣从“给你挑刺”变成“听你讲项目”。最稳妥的回答是讲下单逻辑中的事务处理与并发库存控制先说需求背景再说实现方案最后说测试中发现的问题和解决过程。数据库表是怎么设计的先说核心表有哪些再说表与表之间的关系最后着重讲订单表为什么单独拆成主表和明细表为什么明细表要冗余商品快照信息。项目中遇到过哪些问题选两个真实的问题来说比如端口占用、图片上传后不显示、订单取消但库存没恢复然后讲定位过程和解决办法。真实的问题比套话更打动评委。6.3 临场演示与系统界面的注意事项演示环节是答辩的“开卷考试”提前把演示路线设计好流畅程度直接影响评分。我的建议演示顺序是先展示前台——注册新用户或直接用现成账号登录浏览图书列表和分类搜索一本书点进详情加入购物车结算下单。然后切换管理员账号转到后台找到刚才的订单发货。最后再登录普通用户确认收货。这一条闭环走下来系统的所有核心功能全部覆盖评委也能通过这条线快速理解项目逻辑。有几个细节提醒一下演示前把所有窗口清好只留需要的页面提前把图片和测试数据准备好不要现场临阵磨枪如果演示过程中页面白屏别慌看一眼控制台用最快的速度解释一句“可能是网络慢我刷新一下”然后正常继续。最后分享一个我个人的经验毕设项目做到这里其实已经不是为了应付答辩了。你花在这套图书商城上的时间换来的是对Springboot生态、数据库建模、事务与并发、项目部署这一整条链路的第一手经验。面试的时候能把其中任何一个环节讲出细节都比简历上堆十个熟悉框架管用。如果后续还有时间可以在这个项目基础上加一两个自己的灵光一闪比如用Redis做首页缓存热榜或者把订单模块改造成定时任务自动超时关闭。多走一步这个项目就不再是一个毕设题目而是你自己代码路上的起点。