企业官网建设流程全解析

毕业设计年年有，但图书馆管理系统几乎是每年都会出现的“老熟人”。这个题目听起来简单，实际上涵盖了一个完整Web业务系统的全部链路：后端框架选型、前端页面交互、数据库设计、权限控制、部署上线甚至论文撰写，全部都占全了。用SpringBoot+Vue+MySQL这套组合去做，恰好是当前市场上最主流、招聘需求里出现频率最高的技术栈，所以这个项目拿来做毕业设计，性价比其实很高。

我这篇博文就围绕这个“图书馆管理系统平台”来聊，从选题逻辑、功能拆解、数据表设计、后端接口实现、前端联调、部署上线到论文答辩准备，一条线讲完。文章里的所有细节和步骤不是我凭空编的理论，而是基于实际开发和部署过程中最常见的方案整理出来的，尽量做到你照着做就能把系统搭起来、跑通、甚至通过答辩。

1. 为什么“图书馆管理系统”能成为毕业设计常青树

每个学校每个年级都有大量学生选这个题目，难免让人觉得“太大众了”。但从实际角度出发，大众并不等于平庸，关键是看你怎么把它做出层次感。

1.1 选题逻辑：功能域横跨计算机核心技术知识点

做毕业设计最怕什么？不是题目难，而是题目窄。有的题目是做一个“验证码识别工具”，有的是做一个“个人博客”，功能域非常有限，做完之后写论文都凑不够字数。

图书馆管理系统刚好相反，它天然覆盖了这些核心模块：

• 用户认证与权限管理：读者、图书管理员、系统管理员三种角色，对应JWT登录、角色鉴权、菜单权限控制
• 图书管理：图书信息CRUD、分类管理、库存管理、条形码/ISBN处理
• 借阅业务流程：借书、还书、续借、逾期处理、预约，这是一个完整的状态机流转过程
• 检索与筛选：按书名、作者、ISBN、分类多条件组合查询，涉及前后端联调
• 统计报表：借阅量统计、热门图书排行、读者活跃度，涉及SQL聚合查询
• 基础配置：办证、罚款设置、借阅规则设定

这些模块每一个都能在计算机专业课程里找到对应：数据库原理对应表结构设计，软件工程对应需求分析与用例建模，Java Web对应后端接口开发，前端课程对应Vue组件开发。答辩的时候，评委问任何一个方向，你都能拿出对应的课程基础来应答，这就叫“题目覆盖面广的天然优势”。

1.2 技术栈的合理性：SpringBoot+Vue+MySQL为什么是主流

现在再去用JSP+Servlet做这种系统，虽然能跑，但答辩时很容易被老师问“为什么不用主流框架”。SpringBoot之所以成为事实标准，核心原因是它把Spring家族的配置复杂度降到了最低，内嵌Tomcat，打成一个jar包就能直接运行，非常适合毕设这种“要快速交付又要保证稳定”的场景。

Vue则是目前前端领域上手曲线最平滑的框架之一，它的双向绑定和组件化开发方式，让一个以后端为主的开发者也能独立完成管理后台的前端界面。配合Element UI这类组件库，表格、表单、弹窗、分页这些后台管理系统的“标准件”，基本不需要从零写样式。

MySQL更不用多说，开源、稳定、资料多，任何报错基本都能搜到解决方案。这三个组合在一起，是当前毕业设计里最稳妥也最有说服力的技术方案。

1.3 这套题目适合什么样的学生

说实话，这个题目的难度属于中等偏下。如果你是以下情况，选它就很合适：

• 有一定Java基础，但没独立做过完整项目
• 准备时间有限，可能只有两到三个月的课余时间
• 需要把精力分一部分在找工作或考研上，毕设不能占用太多精力
• 论文想写得扎实一点，需要有足够的图表和数据支撑

反过来，如果你已经做过两三个完整项目，想挑战高难度，那这个题目确实有点不够看，可以考虑往“基于推荐算法的智慧图书馆系统”方向升级。

2. 系统功能拆解：三种角色和一条核心业务流程

功能设计是开发前最重要的一步。很多同学拿到题目就急着建表写代码，结果做到一半发现功能对不上，回头改表结构，浪费大量时间。先把功能地图理清楚，后面每一步都会顺畅很多。

2.1 角色权限模型的建立

图书馆管理系统最常见的角色划分是三种：

在实现上，后端使用Spring Security或JWT配合拦截器实现接口级权限控制，前端通过Vue Router的路由守卫根据角色动态生成菜单。权限控制做到什么程度，直接决定答辩时老师问“系统安全性”你能答出多少内容。

2.2 核心业务流程：借书到还书的完整状态流转

整个系统最重要的一条业务线是借阅流程。这条流程定义不清楚，数据库设计和接口设计都会出问题。

正常流程是这样的：

1. 读者在系统检索图书，确认库存充足且有借阅资格
2. 提交借阅申请，或直接到管理员处办理借书
3. 系统校验：读者是否有逾期未还图书、是否达到最大借阅数量、图书是否下架
4. 校验通过后生成借阅记录，图书库存减一
5. 到期前读者可以续借，续借次数通常限制为一次
6. 超期未还，系统自动计算逾期天数，生成罚金记录
7. 还书时库存加一，借阅记录状态更新为“已还”

这个状态机看着简单，实际编码时容易漏掉异常分支，比如“借书时图书刚好被删除”“续借时已经被预约”“还书时记录不存在”等。这些边界情况的处理，恰好是论文里写“系统健壮性”的素材，也是答辩老师喜欢追问的点。

2.3 功能清单参考

基于角色和流程，具体的功能模块可以拆成这样：

• 系统管理：用户登录、验证码、修改密码、角色管理
• 图书管理：图书分类管理、图书信息维护、批量导入
• 流通管理：借书登记、还书登记、续借处理、逾期罚款管理
• 读者管理：读者信息维护、办证/停用、借阅状态查询
• 统计报表：借阅量统计、图书借阅排行、读者借阅排行
• 个人中心：我的借阅、我的罚金、个人信息修改

这些功能做完，不管你的论文写“基于B/S模式的图书管理系统”还是“基于SpringBoot的智慧图书馆平台”，内容支撑都足够了。

3. 数据库设计：核心表结构与字段细节

数据库是系统的基础，也是毕设论文里必不可少的一章。很多同学建表只求字段够用，但答辩时老师翻数据库，一眼就能看出设计功底。图书馆管理系统的数据表通常有十几张，核心的几张表设计好了，整个系统的根基就稳了。

3.1 用户表与角色表的拆分

用户表不能只存一个用户名和密码就结束。对图书馆系统来说，读者的借阅状态、可借数量、当前借阅数、状态（正常/停用）这些字段，直接影响借阅业务判断。

用户表（sys_user）的设计思路：

• id：主键，使用自增或雪花ID
• username：登录名，唯一索引
• password：加密后的密码（BCrypt加密，绝不能明文）
• real_name：真实姓名
• status：账号状态，正常/锁定/停用
• create_time、update_time：创建和更新时间

角色表（sys_role）和用户角色关联表（sys_user_role）做多对多关联，这样后续扩展角色时不用改表结构。

3.2 图书表的关键字段取舍

图书表（book）除了常规的书名、作者、ISBN、出版社、出版日期、价格、简介之外，有字段特别值得注意：

• book_status：图书状态，在馆/借出/下架/丢失
• stock：库存总量
• current_stock：当前可借数量
• category_id：分类ID，关联分类表
• hot_count：借阅次数，用于热门图书排行
• cover_url：封面图地址

stock和current_stock分开设计是有讲究的。如果只有总库存，每次借还书都要去借阅记录表里count一下才知道剩余量，数据量大时性能很差。用current_stock字段实时维护，借书减一、还书加一，简单高效。

3.3 借阅记录表的状态与约束

借阅记录表（borrow_record）是整个系统中数据增长最快的表，也是设计上最容易出问题的表。

核心字段：

• id：主键
• user_id：读者ID，关联用户表
• book_id：图书ID，关联图书表
• borrow_time：借出时间
• due_time：应还时间，由借阅规则计算
• return_time：实际归还时间，未还时为空
• status：借阅中/已归还/已逾期/已续借
• renew_count：续借次数
• fine_amount：罚款金额

这里特别要注意设计一个逻辑：同一本书在同一时间只能被一个读者借出，这个约束不一定要靠数据库唯一索引实现（因为唯一索引锁的是字段值，无法直接锁“记录的状态”），而是要在借书接口里通过事务和行锁来处理。这个点在论文里写出来非常加分，说明你考虑到了并发场景。

3.4 表关联关系图

数据库设计完成后，表和表之间的关联关系，在论文里是要画ER图的。我们心里要有数：

• sys_user 和 sys_role 通过 sys_user_role 关联
• book 和 book_category 多对一
• borrow_record 同时关联 sys_user 和 book
• fine_record 关联 borrow_record，记录罚金的产生和缴纳

MySQL版本建议用8.0，字符集用utf8mb4，排序规则用utf8mb4_general_ci或utf8mb4_unicode_ci，因为utf8mb4才能完整支持生僻字和表情符号。建表语句写好后，可以直接用Navicat或DataGrip导成SQL脚本，作为项目数据库初始化文件。

4. SpringBoot后端：鉴权、借阅业务与接口设计

后端的核心工作就是把业务逻辑做成规范的RESTful接口，供前端调用。图书馆管理系统不大，但麻雀虽小五脏俱全。这里重点聊几个容易写出“业余感”的地方。

4.1 项目结构应该如何组织

不要所有的代码塞在一个包里。建议按模块分包：

com.library ├── common（通用工具、统一返回结果、异常处理） ├── config（跨域配置、MyBatis配置、JWT配置） ├── controller（接口层） ├── service（业务层） ├── mapper（数据访问层） ├── entity（实体类） ├── dto（前端传入参数对象） ├── vo（返回给前端的视图对象） └── utils（工具类）

统一返回结果类（Result）的设计很关键。让所有接口返回固定格式：

{ "code": 200, "message": "操作成功", "data": {}, "timestamp": 1711240000000 }

前端拿到这个结构才能统一处理成功失败、错误提示，避免每个接口各写一套返回格式，前后端联调时扯皮。

4.2 登录鉴权使用JWT还是Session

图书馆管理系统用JWT来做无状态登录是主流做法。流程不复杂：

1. 用户提交用户名和密码
2. 后端校验，成功则生成JWT令牌返回给前端
3. 前端把令牌存在本地存储（localStorage或Pinia状态管理）
4. 之后每次请求都在请求头里带上Authorization: Bearer token
5. 后端拦截器验证token，拿到用户角色，决定是否放行

关键代码如下（简化版拦截器逻辑）：

public class JwtInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { if ("OPTIONS".equalsIgnoreCase(request.getMethod())) { return true; // 放行预检请求 } String token = request.getHeader("Authorization"); if (StringUtils.isBlank(token)) { throw new BusinessException(401, "未登录或token已过期"); } // 解析token，将用户信息放入ThreadLocal LoginUser loginUser = JwtUtils.parseToken(token.replace("Bearer ", "")); UserContext.set(loginUser); return true; } }

这里有一个容易被忽略的点：拦截器别忘了放行登录接口、验证码接口和Swagger文档路径，否则前端连登录都请求不通。

4.3 借书还书的事务与并发控制

借书接口的设计，最能看出一个人的后端功底。如果只是简单的“插入一条借阅记录，图书stock减一”，在并发条件下会出现超借问题。

正确的做法是：

1. 开启事务
2. 使用SELECT ... FOR UPDATE锁住图书记录
3. 检查current_stock是否大于0
4. 检查读者是否存在逾期未还记录
5. 检查读者当前借阅数量是否达到上限
6. 插入借阅记录，图书current_stock减一
7. 提交事务

@Transactional public BorrowResultVO borrowBook(Long userId, Long bookId) { // 行级锁，防止并发超借 Book book = bookMapper.selectByIdForUpdate(bookId); if (book == null || book.getCurrentStock() <= 0) { throw new BusinessException("图书不存在或库存不足"); } int borrowCount = borrowRecordMapper.countBorrowing(userId); // 判断是否超过最大借阅数 if (borrowCount >= userService.getMaxBorrowCount()) { throw new BusinessException("已达到最大借阅数量"); } // 生成借阅记录 BorrowRecord record = new BorrowRecord(); record.setUserId(userId); record.setBookId(bookId); record.setBorrowTime(new Date()); record.setDueTime(DateUtil.addDays(new Date(), borrowRule.getMaxBorrowDays())); record.setStatus(0); borrowRecordMapper.insert(record); // 扣减库存 bookMapper.decreaseStock(bookId); return new BorrowResultVO(record); }

这段逻辑里所有失败情况都抛异常，事务自动回滚，代码非常简洁但又严谨。写论文时把这部分涉及的“视图、事务、锁机制”展开写，对应的就是数据库原理课的“并发控制”章节。

4.4 检索功能的SQL优化点

图书检索是使用频率最高的功能，需要支持多条件组合查询。最容易踩的坑是SQL拼接时空条件处理不对，结果导致查不到数据。推荐用MyBatis的动态SQL标签来写：

<select id="searchBooks" resultType="com.library.vo.BookVO"> SELECT * FROM book <where> <if test="keyword != null and keyword != ''"> AND (title LIKE CONCAT('%', #{keyword}, '%') OR author LIKE CONCAT('%', #{keyword}, '%') OR isbn LIKE CONCAT('%', #{keyword}, '%')) </if> <if test="categoryId != null"> AND category_id = #{categoryId} </if> <if test="status != null"> AND book_status = #{status} </if> </where> ORDER BY id DESC LIMIT #{offset}, #{pageSize} </select>

为了提升查询效率，title字段和isbn字段建议加普通索引。数据量小于一万条的毕设项目，其实不需要做太复杂的索引优化，但这层思考必须写进论文。

5. Vue前端：页面架构、路由守卫与接口联调

前端的开发量和后端差不多，尤其后台管理类系统，大量重复的表格表单页面。用Vue加UI组件库能把工作量压缩掉一半以上。

5.1 前端项目结构和依赖

创建Vue项目建议直接用Vite，比webpack的启动速度快很多。核心依赖：

• vue-router：前端路由
• pinia或vuex：状态管理
• axios：HTTP请求封装
• element-plus：UI组件库
• sass：样式预处理器
• echarts：统计图表（做报表时用）

项目结构按页面模块分文件夹，每个页面一个vue文件，公共组件放components，接口请求统一放api目录。

5.2 路由守卫实现菜单权限控制

前端不能只靠隐藏菜单来做权限控制，必须结合路由守卫。在路由配置里给每个页面标记需要什么角色，然后在router.beforeEach里判断当前用户角色是否匹配：

router.beforeEach((to, from, next) => { const token = localStorage.getItem('token') if (!token && to.path !== '/login') { next('/login') return } const userInfo = JSON.parse(localStorage.getItem('userInfo') || '{}') if (token && to.meta.roles && !to.meta.roles.includes(userInfo.role)) { next('/403') return } next() })

这里有一个经验：用户的角色和基本信息在登录成功后，除了存token之外，把用户信息也缓存一份在本地。因为刷新页面时，Vue实例重新创建，内存里的状态全没了，要用缓存的用户信息去恢复菜单和权限。

5.3 Axios封装与接口对接

不封装直接在每个页面里写axios请求，会出现大量重复代码，而且错误处理没法统一。建议统一封装：

import axios from 'axios' import { ElMessage } from 'element-plus' import router from '@/router' const service = axios.create({ baseURL: '/api', timeout: 10000 }) // 请求拦截器，自动携带token service.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers['Authorization'] = 'Bearer ' + token } return config }) // 响应拦截器，统一处理错误 service.interceptors.response.use( response => { const res = response.data if (res.code !== 200) { ElMessage.error(res.message) if (res.code === 401) { router.push('/login') } return Promise.reject(new Error(res.message)) } return res.data }, error => { ElMessage.error('网络请求失败，请稍后重试') return Promise.reject(error) } ) export default service

这样封装之后，页面里的业务代码就非常干净了，直接调接口拿数据，不用每次写错误处理。

5.4 表格分页与条件查询的坑

管理后台最典型的页面就是“带搜索条件的表格”。这里容易犯的错误是：搜索条件和页码不同步。用户改了一个搜索条件之后，页码应该重置为1，不然可能停留在一个超过总页数的页码上，结果列表空白。

另外，Element Plus的el-table分页组件里current-page和page-size是单向绑定的，切换页码时需要调用后端接口。想清楚这一点，搜索、重置、翻页这三个操作的联动就自然了。

6. 本地开发到部署上线：一套可复现的完整路线

开发完成后，部署上线是很多同学的短板。有些人的毕设只能在本地跑到花里胡哨，一上服务器就各种报错，所以这一部分我把自己的部署经验完整分享一下。

6.1 本地开发环境搭建清单

在开始部署之前，先把本地环境准备好。不要嫌基础，很多同学的问题恰恰出在这一步：

• JDK版本：推荐JDK 8或11，对应SpringBoot 2.x版本
• Maven：3.6以上，配置好阿里云镜像加速依赖下载
• Node.js：16以上版本，用来跑Vue项目
• MySQL：8.0版本，安装时一定要记住root密码
• 开发工具：IDEA（后端）、VS Code（前端）

我的建议是前后端分两个项目目录管理，后端一个maven项目，前端一个npm项目，不要混在一起。到时候打部署包也是分开打。

6.2 后端打包过程中最常见的两个问题

第一个是打包时跳过测试。SpringBoot项目如果里面写了单元测试，打包时默认会执行测试类，一旦测试类里连接了数据库而数据库没启动，打包就会失败。用这个命令跳过：

mvn clean package -DskipTests

第二个是配置文件里的数据库连接地址容易写错。本地是localhost，服务器上要改成对应的IP或域名，账号密码也要对应修改。建议把环境相关的配置独立到application-prod.yml里，打包时用profile激活，避免每次部署改代码。

6.3 服务器部署的两种路线

部署方式有两种，根据自己的实际条件选择。

路线一：云服务器 + Docker Compose

对有一定Linux基础的同学来说，用Docker Compose把MySQL和后端服务容器化是最省事的。大概步骤是：

1. 服务器安装Docker和Docker Compose
2. 准备好mysql的初始化SQL脚本
3. 写一个docker-compose.yml，定义mysql和app两个服务
4. 后端打包成jar后挂载进容器启动
5. Nginx用docker或宿主机方式反代前端静态文件和/api请求

路线二：云服务器 + 宝塔面板

不想折腾命令行的用宝塔，图形化界面操作更直观：

1. 安装宝塔面板
2. 安装Nginx、MySQL 8.0
3. 上传后端jar包，配置一个Java项目，指定端口7001
4. 上传前端dist目录，配置Nginx静态站点
5. Nginx配置反向代理，把/api开头的请求转发到7001端口

无论用哪种方式，有几件事都必须做：MySQL的root账号不允许远程登录或只用强密码；后台管理路径不要用默认路径；服务器安全组端口要放行指定端口而不是全部放行。

6.4 Nginx反向代理配置示例

前后端分离项目必然要处理跨域。开发时用Vite的proxy代理解决，生产环境用Nginx反向代理解决。核心配置如下：

server { listen 80; server_name your-domain.com; root /usr/share/nginx/html; index index.html; location / { try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:7001/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }

有一个特别容易踩的坑：前端axios的baseURL如果是/api，后端接口路径是/book/list，Nginx代理转发时要注意proxy_pass后面是否带斜杠。带斜杠会把/api前缀去掉，不带斜杠会把完整路径转发给后端。两种都可以，但前后端必须约定一致，否则就会出现404。

6.5 部署完成后的验证清单

部署不是“页面能打开”就算完，建议对照这个清单逐一验证：

• 管理端能否正常登录，登录失效后是否被拦截
• 图书新增和编辑后，列表是否有刷新缓存问题
• 借书流程和还书流程是否正常，库存变化是否正确
• 搜索条件与分页联动是否正常
• 统计报表图表是否有数据
• 刷新页面后路由是否正常，菜单是否正确恢复
• 非对应角色访问受限页面时是否跳转到403页

每个问题对应的修复方法都不同，但大类来说就是前端缓存问题、后端路径问题、数据库连接问题这三类。部署一次你就全知道了。

7. 论文写作思路与答辩准备

很多功能做得很好的人，论文写得稀烂，最后被老师塞了一堆修改意见。论文和代码是两回事，代码是写给人之外的东西跑的，论文是写给老师看的，逻辑一定要顺。

7.1 论文各章节的核心内容建议

按照学校给的模板走，一般都有固定的章节结构，内容可以这样填：

• 绪论：写研究背景与意义，但不要空谈“随着信息技术的发展”，尽量落点到当前图书馆管理工作中手工登记效率低、图书信息不透明、读者借阅体验差这些具体问题
• 相关技术介绍：概述SpringBoot、Vue、MySQL、MyBatis-Plus，可以结合项目说明为什么用，避免纯百度式罗列
• 需求分析：画出用例图，写出功能需求和非功能需求，特别是从业务流程里提炼的角色用例
• 系统设计：总体架构图（前后端分离架构）、功能模块划分、ER图、表结构设计、核心业务流程图
• 系统实现：按模块介绍关键页面和核心代码，重要的是写清楚设计思路和关键代码的作用，不要整段贴代码
• 系统测试：写测试用例表，覆盖登录、权限、借阅流程、搜索、统计等功能点；性能和数据一致性测试简单提一下即可

7.2 论文里的图表要注意什么

计算机专业论文特别看重图表。图要清晰、有编号、有标题，表要规范、有含义。常见的要求是：

• 用例图：理清三个角色的用例，这是需求分析阶段最重要的图
• 系统架构图：画出浏览器到前端再到后端再到数据库的整体链路
• 数据库ER图：至少覆盖用户、图书、借阅记录、分类这几张核心表
• 时序图：借书或还书的整个交互过程用一段时序图表现
• 部署图：画出Nginx、后端服务、MySql之间的关系

图表工作如果拖到最后几天才做会非常痛苦，建议开发完成后马上用Draw.io把核心图表画好，后面写的时候直接引用。

7.3 答辩时老师最可能问的问题

答辩不是背代码，而是看你对系统的理解程度。我把这几年学生被问到的高频问题整理了一下：

• 为什么用JWT而不用Session？各有什么优缺点？
• 如果两个用户同时借同一本书的最后一本，系统怎么处理？
• 数据库索引怎么设计的？查询慢怎么排查？
• 密码加密是怎么做的？为什么用BCrypt？
• 前端路由权限和后端接口权限有什么区别？双端权限如何保障安全？
• 图书逾期费用是怎么自动计算的？定时任务还是实时计算？
• 如果让你扩展一个图书推荐功能，你会怎么做？

这些问题基本都能从项目的核心逻辑里找到答案，只要是自己亲手写的代码，答起来不会慌。

8. 一些题外话和实际经验

文章写到这里，该讲的技术点都讲完了，最后聊几个我实际操作下来的感受。

第一个经验是：尽量提前把部署视频录好。不要等到答辩前一刻才录，因为你永远不知道演示时会发生什么。网络卡顿、服务器挂了、浏览器缓存异常、后台数据被删了，任何状况都可能出现。提前录一个从首页操作到借书还书全流程的视频，时间大概三到五分钟，作为演示兜底，能救命的。

第二个经验是：数据库里要预先造一批干净规范的演示数据。不要用随便导入的脏数据，比如读者姓名就得像读者姓名，图书ISBN要像真实存在的ISBN，分类要合理。数据越整洁，演示时给人感觉越专业。另外可以刻意造几条有代表性的数据，比如一本被借出多次的热门图书、一个有过逾期记录的读者，展示统计报表时会非常好讲。

第三个经验是：代码注释一定要写规整。这不是给别人看的，是给未来的自己看的。很多同学写好代码放两三周再回头看，已经完全忘了某个模块为什么那么设计。尤其论文里需要贴代码截图，注释写得清楚，老师和自己的体验都会好很多。

第四个经验是：尽量自己把每个功能点都手动过一遍测试。不要觉得能登录能查书就完事了。还书时连续点两次提交会不会重复还？借书数量到上限后借下一本提示是否友好？修改图书分类时关联的图书是否同步更新？这些细节就是区分“能跑的程序”和“像样的项目”的分界线。

最后一个在调试阶段特别有用的经验：前端请求报错时不要只看浏览器控制台的错误输出，要打开NetWork面板看具体请求状态码和响应体。401是登录失效，403是权限不足，404是路径不对，500是后端异常。后端日志里面那条Exception堆栈才是定位问题的钥匙。把“看后端日志”变成你的第一反应，排查效率会提高很多。

如果这篇东西能帮你把系统搭起来、把论文写出来、顺利通过答辩，那花时间写这些内容就值了。