又是一年春招毕设季后台收到好几个同学私信学长选了这个“基于SpringBoot高校毕业生离校登记管理系统小程序”的题目源码也拿到了但是不知道从哪里开始看部署也没搞定论文更是无从下笔。问的人一多我觉得干脆把这套题目的完整实现思路和部署经验整理出来。这个题目在计算机毕设里属于典型的“看着简单、做起来有货”。表面看就是一个离校信息登记页面实际背后要处理微信小程序登录、学生申请、多角色审批、数据统计、文件上传、状态流转这些核心环节还牵扯到Spring Boot后端跟前端小程序的接口联动。如果再算上论文LW、部署说明、演示视频它几乎把毕业设计要考察的所有环节都覆盖了。这篇文章我不打算只贴代码而是站在一个帮你把毕设真正跑通、能讲清楚、能通过答辩的角度从需求边界、技术选型、数据库设计、核心功能实现、部署上线到避坑经验把整个链路完整走一遍。不管你是自己选的题目还是接手别人的源码都能从这里找到可以直接落地的思路。1. 离校登记管理系统到底要管什么需求边界先划清楚1.1 离校登记不只是填一张表单很多同学拿到题目后第一反应是这不就是一个表单录入页面吗学生填一下离校信息管理员在后台看一眼。如果真这么理解那你的毕设做出来会很单薄。高校离校登记的本质是毕业季的流程管理。一个学生要离校不是自己填完表格就算结束他需要完成一系列手续的确认比如图书归还、宿舍退宿、学费和校园卡结算、党团组织关系转接甚至还有档案去向确认。每个环节对应一个责任部门或者审核角色。系统要做的事情就是把这些分布在线下的流程搬到线上让数据跟着角色走让审批状态实时可见。所以你在需求分析阶段就要意识到系统至少包含三个方向学生端提交离校登记申请填写个人信息、离校时间、去向、联系方式并实时查看自己的审批进度。辅导员或学工端审核学生的申请确认该生是否满足离校条件可以驳回并要求补充材料。系统管理员端维护院系、学生基本信息、离校类型查看全校离校进度导出统计数据。明确这三类角色后整个系统的功能边界才算立住。1.2 三类用户角色和他们的使用场景我把这个系统在实际使用中的典型场景拆开来说这样你做需求分析和画用例图的时候会有更清晰的参照。学生端的核心场景是“申请与查看”。学生打开小程序微信授权登录后系统自动识别身份。他需要完善自己的基础信息然后选择离校类型比如正常毕业、提前离校、结业填写离校日期、就业或升学去向、紧急联系人信息提交后等待审核。在这之后他最关心的就是状态变化是“待审核”“已通过”还是“被驳回”被驳回的原因是什么。辅导员端的核心场景是“审核与反馈”。毕业季一个辅导员可能要面对几十上百个学生如果一个个翻聊天记录收表格效率极低。系统应该提供一个待办列表按提交时间排序辅导员可以快速查看学生提交的登记信息一键通过或者填写驳回意见同时按班级筛选未提交的学生名单方便线下催办。管理员端的核心场景是“维护与统计”。管理员要维护院系列表、核对学生的学号姓名、配置离校流水单的各类项目还要查看整个学院甚至全校的离校完成率。这些统计数据在答辩时非常有用你可以做成简单的柱状图也可以直接导出一张Excel表格当演示素材。1.3 功能清单哪些是必须的哪些是加分项我整理了一份功能优先级你对照着看做毕设时先保必须项有余力再加加分项优先级功能模块说明必须微信小程序登录前端wx.login获取code后端换取openid识别用户身份必须学生离校登记填写离校类型、时间、去向、备注等信息必须审批管理教师端待办列表支持通过、驳回、填写意见必须进度查询学生端查看自己申请的状态流转记录必须学生信息管理管理端维护学生、院系基础数据必须统计看板离校人数、完成率按院系统计加分消息通知审核结果通过模板消息或系统消息推送给学生加分文件上传学生上传就业协议、转接证明等附件加分数据导出导出Excel格式的离校清单加分多级审批辅导员审批后由院系管理员再确认这里的每一块在论文里都能对应到“功能模块设计”一个小节。如果你论文篇幅不够把加分项加进去内容立刻充实起来。2. 技术栈定档Spring Boot 小程序这套组合的取舍2.1 为什么后端选Spring BootSpring Boot在毕业设计里的统治地位不是没有原因的。首先它对新手极度友好。不需要像传统SSM那样手动配置一大堆XML文件一个starter依赖加进去自动配置就把场景初始化好了这让你的精力可以集中在业务代码上而不是耗在环境配置里。其次它的生态成熟度无可替代。Spring Boot MyBatis-Plus MySQL这套组合网上能找到海量示例出现任何问题都可以快速搜索到解决方案。从前面的热搜词也能看到springboot面试题、springboot教程、springboot配置这些词常年热度不减说明这是一个已经被验证过无数次的成熟技术栈。再次对于毕设来说Spring Boot内置的Tomcat容器也非常方便。本地开发直接运行main方法部署时打包成jar包用一条java -jar命令就能启动完全不需要额外安装配置独立的Tomcat。这一点在部署环节对你的帮助是决定性的。2.2 小程序端为什么比H5或者App更合适题目选择了微信小程序作为前端载体我觉得这是一个很聪明的选择原因有三点。第一是用户体验的门槛低。微信小程序不用下载安装学生扫码或者搜索就能打开这非常契合毕业季离校登记这个轻量化使用场景。学生不会为了登记一次离校专门去装一个App。第二是微信生态给了身份识别的天然方案。小程序端通过wx.login机制可以拿到临时的code后端再通过该code向微信接口换取openid这个openid是微信用户的唯一标识可以直接和学生账号绑定省去了繁琐的注册、登录流程。用户第一次打开就是“免登录”体验这对于校园场景尤其重要。第三是前端开发成本可控。微信小程序原生的WXML、WXSS、JavaScript的模式如果你做过后端开发学起来不会太难。而且开发者工具自带模拟器调试很方便。当然小程序也有它的限制。最典型的就是所有网络请求的域名必须在小程序管理后台配置白名单并且线上环境强制要求HTTPS协议。这些限制在测试阶段可以通过开发工具勾选“不校验合法域名”来跳过但线上发布时必须解决。2.3 项目整体结构怎么组织准备动手写代码前先把工程结构想清楚。后端我建议采用标准的单体分层架构springboot-departure-admin/ ├── src/main/java/com/example/departure/ │ ├── controller/ # 前端接口入口 │ │ ├── UserController.java │ │ ├── StudentController.java │ │ └── DepartureController.java │ ├── service/ # 业务逻辑层 │ │ ├── UserService.java │ │ └── DepartureService.java │ ├── mapper/ # 数据访问层MyBatis-Plus的Mapper接口 │ │ ├── UserMapper.java │ │ └── DepartureMapper.java │ ├── entity/ # 数据库实体类 │ │ ├── User.java │ │ └── DepartureRecord.java │ ├── common/ # 公共类统一返回体、异常处理、工具类 │ │ ├── Result.java │ │ └── JwtUtil.java │ └── DepartureApplication.java # Spring Boot启动类 └── src/main/resources/ ├── application.yml └── mapper/ # MyBatis XML文件如果需要前端小程序的目录结构建议这样划分miniprogram/ ├── pages/ │ ├── index/ # 首页/离校登记入口 │ ├── login/ # 登录页 │ ├── apply/ # 离校登记表单页 │ ├── record/ # 申请记录列表页 │ ├── detail/ # 记录详情页 │ └── mine/ # 个人中心页 ├── utils/ │ ├── request.js # 封装wx.request请求 │ └── auth.js # 登录状态管理 ├── app.js # 小程序逻辑入口 ├── app.json # 小程序全局配置 └── project.config.json # 开发者工具项目配置前后端通过JSON接口交互所有接口返回统一的结构体这一点后面专门讲是联调顺畅的关键。3. 数据库设计围绕“离校登记”的5张核心表3.1 用户与角色拆分的思路数据库设计是答辩时老师一定会追问的部分你必须能讲清楚每张表是干什么的以及表之间的关系。第一张是用户表。我习惯叫user它只存登录凭证和角色信息核心字段包括主键id、微信openid、角色类型role、创建时间。这里有一个设计细节值得说明既然选了微信免登录为什么还要单独建一张用户表而不是直接在学生表里存openid原因在于角色和账号的分离。学生以后登录是学生但教师也有自己的微信账号管理员也可能通过小程序做一些简单的维护操作。如果把openid直接写进学生表教师和管理员的身份就没有地方挂靠了。所以更好的做法是统一在user表里维护账号身份学生表通过user_id字段和user表关联。第二张是学生信息表student。这张表存学生的基本档案学号student_no、姓名name、性别gender、所属院系college_id、专业major、班级class_name、手机号phone、邮箱email、是否已离校status等。学生表里面的user_id字段是用来关联user表的。第三张是院系表college不要小看这张表。有了它管理员才能维护院系列表学生注册时才能选择自己的院系统计时才能按院系分组。字段很简单id、院系名称college_name、编码code。3.2 离校申请表的字段设计是核心中的核心接下来是整张设计的核心——离校登记表departure_record。它的字段决定了业务逻辑能走多远我建议至少包含以下内容字段名类型说明idbigint主键student_idbigint关联学生表categoryvarchar离校类型正常毕业、提前离校、结业等leave_datedate离校日期destinationvarchar离校去向就业城市、升学学校destination_detailvarchar详细去向如单位名称/学校名称contact_phonevarchar离校后联系电话remarkvarchar备注信息statustinyint审核状态0待审核、1通过、2驳回apply_timedatetime提交申请时间approve_user_idbigint审核人idapprove_timedatetime审核时间approve_remarkvarchar审核意见deletedtinyint逻辑删除标记其中status字段是状态流转的关键。我建议用数字表示状态而不用字符串原因有两点一是数据库存储空间更小二是后端代码里判断逻辑更简洁if (record.getStatus() 0)一眼就能看出这是待审核状态。deleted字段是逻辑删除按逻辑删除可以保留完整的申请历史尤其是在审批流场景下如果物理删除了记录关联的审批日志就找不到对象了后续统计也可能出错。3.3 审批日志表让每一次操作有迹可循很多同学会忽略审批日志表但这是答辩时一个很好的加分点。approval_log表记录每一次审批操作字段包括id、登记记录ID record_id、操作人ID operator_id、操作类型 action通过/驳回、操作意见 comment、操作时间 create_time。为什么需要这张表因为学生端要展示审批进度需要知道“谁在什么时候做了什么处理”。有了审批日志表进度的展示就是一次简单的列表查询不用去业务表里硬抠数据。同时这张表也为论文里的系统测试提供了很好的素材你可以写下“提交申请后辅导员执行通过操作审批日志表新增一条记录学生端进度更新为已通过”这样的完整测试用例。考虑到数据量这几张表不需要做非常复杂的索引设计。但有两个建议一是departure_record表的student_id字段建议加索引因为学生端最核心的查询是“查我的申请列表”按student_id过滤的场景最多二是departure_record表的status字段可以考虑加索引因为管理端按状态筛选待办列表是高频操作。4. 后端与小程序端对接登录、登记、审批的完整实现4.1 微信登录的完整链路从code到openid微信小程序登录是整个系统的入口也是很多新手卡住的地方。我先把这个过程讲通透。小程序端调用wx.login()后会拿到一个临时登录凭证code这个code的有效期只有五分钟并且只能使用一次。然后前端需要把这个code发给后端由后端拿着code加上小程序的appid和secret去微信的接口换取openid。后端在这一步的核心代码如下// 使用RestTemplate或HttpClient调用微信接口 String url https://api.weixin.qq.com/sns/jscode2session?appid appid secret secret js_code code grant_typeauthorization_code; // 解析返回结果获取openid // {openid:xxx,session_key:xxx,expires_in:7200}拿到openid之后先查询user表是否存在该openid的记录。如果不存在说明是第一次使用小程序的用户这时候需要判断他需要以什么角色进入系统。因为这是离校登记系统大多数用户是学生所以可以在首次登录时自动注册一个学生角色账号并跳转到一个完善身份信息的页面让学生填写学号、姓名、院系等信息。如果存在直接查询对应的用户信息返回给前端。需要注意的是session_key绝对不能下发到前端。它是微信用于解密用户敏感数据的密钥一旦泄露就意味着用户数据可能被破解。后端拿到session_key后应该立即丢弃或者安全存储只把openid映射成自己系统的用户ID再生成一个自定义的登录态token返回给前端。关于自建登录态我建议使用JWT。前端拿到token后存储在本地缓存中之后每次请求在请求头里带上后端用一个拦截器解析token识别当前用户。这个过程和校园卡刷门禁是同一个逻辑门禁系统不看你是谁只看你手里那张卡是否有效。4.2 前后端分离下的统一返回体设计前后端联调时最痛苦的事情就是接口返回格式不统一这边返回{code:0, data:{...}}那边直接返回{success:true, result:{...}}前端解析时要写一堆一堆的判断逻辑。好的做法是在后端定义一个统一的返回体public class Result { private Integer code; // 200成功500失败401未登录 private String message; // 提示信息 private Object data; // 返回的业务数据 }所有的controller接口无论成功还是失败都返回这个结构。前端的request.js只需要对code统一做一次判断成功就拿出data失败就弹出message。这样就把异常处理收敛到了一个地方前端代码会干净很多。4.3 学生端离校登记的交互流程小程序端的学生离校登记页面我建议设计成一个分步骤的表单避免用户一上来就看到十几个字段产生焦虑感。第一步是身份信息确认从后端拉取当前学生的基本信息并展示有错误可以修改。第二步是离校信息填写包括离校类型、离校日期、去向、单位名称等。第三步是联系信息确认填写离校后的联系电话和紧急联系人。最后点击提交前端把数据组装成一个JSON对象调用POST /api/departure/apply提交到后端。后端接口在接收到请求后需要做以下几件事先取当前登录用户的ID通过user表找到student_id然后组装departure_record记录初始化状态为0待审核插入数据库。这里要注意用户只能提交一次有效的离校登记申请如果已经存在一条待审核或者已通过的记录再次提交应该给出友好提示这个校验逻辑在后端实现不能只靠前端按钮的disabled状态。因为接口是可以被直接调用的如果前端禁用了提交按钮但接口不校验恶意用户完全可以通过Postman绕过限制重复提交。4.4 管理端审批接口与状态流转管理端审批功能是体现系统业务价值的地方。接口层面至少有这几个GET /api/admin/departure/pending获取待审核列表可按院系或班级筛选。POST /api/admin/departure/approve审批通过。POST /api/admin/departure/reject驳回申请必须填写驳回原因。审批通过和驳回本质上是在修改departure_record表的status字段但有一个关键细节修改状态的同时一定要在approval_log表插入一条操作日志。这两个操作必须在同一个数据库事务里完成否则可能出现状态已经改了但日志没记录的情况。事务的作用就是保证“要么都成功要么都失败”就像转账操作必须同时扣减付款方和增加收款方余额一样。审批完成后前端页面的状态就是通过查询日志表来展示的。学生端看到的进度是“提交申请 - 辅导员审核通过”每一步都有操作时间和操作人既透明又符合答辩时老师想看完整流程的心理预期。4.5 消息通知的轻量实现方案关于离校审批结果通知很多同学问要不要接入微信订阅消息。我觉得对于毕设来说接入订阅消息是一个加分项但不是必须要做的。原因在于订阅消息的配置流程比较繁琐涉及在小程序后台申请模板、用户主动授权订阅、后端拼接参数发送任何一个环节出错都会耗费大量调试时间。如果时间紧张我建议采用一个轻量方案小程序端在onShow生命周期里重新拉取申请记录实现“回到页面就刷新状态”的效果。同时在记录列表页增加下拉刷新功能学生主动下拉就能看到最新状态。这个方案虽然做不到实时的“服务端主动推送”但从用户体验上看学生重新进入页面就能看到审核结果已经足够满足需求。如果确实要做订阅消息也有一条比较清晰的实现路径小程序端在提交申请时申请“审核结果通知”的订阅授权拿到按钮对应的templateId和用户点击授权返回的res消息后端在审批操作完成后调用微信subscribeMessage.send接口发送通知。这个过程里formId或者一次性模板消息的采集是最容易踩坑的地方建议抽出一整天专门调试。5. 部署与演示不是写完代码就结束了5.1 后端打包部署从开发环境到可运行jar包开发完成后部署这件事越早做越好不要临近提交才手忙脚乱。后端的部署相对简单核心步骤就三步。第一步是修改配置文件。application.yml里的数据源配置要改成生产环境的数据库连接信息数据库要提前在云服务器上建好并导入建表SQL。同时注意MySQL连接的时区参数serverTimezoneAsia/Shanghai这个参数必须要加否则日期时间会出现8小时的偏差。第二步是使用Maven打包。在项目根目录执行mvn clean package -DskipTests打包完成后target目录下会生成一个可执行的jar包。注意打包前先跑一遍Maven的test先把单元测试跑通。就算不写复杂的单元测试至少把启动测试跑一下确认Spring上下文能正常加载。第三步是上传到服务器并启动。把jar包放到服务器任意目录执行nohup java -jar departure-system.jar --spring.profiles.activeprod app.log 21 这个命令的意思是用后台方式启动服务并把日志输出到app.log文件。启动后一定要查看日志确认没有异常用tail -f app.log命令跟踪启动过程。这里有个容易踩的坑就是端口占用。Spring Boot默认端口是8080如果服务器上已经有其他服务占用了8080需要修改server.port参数。另外云服务器的安全组规则也要放行对应的端口否则外部请求到不了你的服务。5.2 小程序端发布域名白名单与HTTPS小程序的发布流程相对固定但有一个前置条件卡住过很多人线上环境的所有网络请求都必须指向在小程序管理后台配置过的合法域名并且这个域名必须支持HTTPS。如果你没有现成的备案域名和SSL证书这在毕设阶段确实是个头疼的问题。我的建议是分两套方案来应对如果你只是需要录制演示视频、在实验室或者宿舍演示给老师看完全可以用开发模式的“不校验合法域名”功能后端直接请求你电脑局域网IP的8080端口。这在校园网环境下完全可行演示效果和线上没有任何区别。只要确保你的电脑和演示用的手机连的是同一个WiFi。如果你希望把小程序真正上线体验一下那就要准备备案域名和HTTPS证书了。域名备案需要时间可能要半个月以上所以务必提前规划。部署结构通常是Nginx作为反向代理监听443端口配置好证书然后转发到本地的Spring Boot服务。这样小程序端的请求地址是https://你的域名/api/xxxNginx把请求转发到http://localhost:8080/api/xxx。Nginx转发配置里有一个很关键的点要保留请求头信息。否则后端通过request获取用户IP时拿到的一律是127.0.0.1。建议在location配置里加上proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;5.3 演示视频和说明文档这些“软材料”怎么准备标题里提到“完整源码LW部署说明演示视频”说明这套题目除了代码之外配套材料也很重要。很多同学代码写完了却在演示视频和部署说明上栽了跟头。演示视频不建议直接用手机对着屏幕录制一段就完事。用OBS或者Windows自带的录屏工具分辨率至少1080p帧率30即可。录制的顺序建议按这样走先打开小程序演示微信登录然后以学生身份提交一条离校登记申请切换角色到教师端演示待办列表和审批操作最后切换到管理端演示学生管理、数据统计界面。整个视频控制在十分钟以内重点突出每一步的操作和界面变化。部署说明文档则要写到“一个完全不知道这个项目是什么的人都能照着操作”的程度。包含环境要求JDK版本、Maven版本、MySQL版本、微信开发者工具版本、初始化数据库的步骤、后端打包运行步骤、小程序导入步骤、以及常见问题排查方向。这份说明文档在答辩时也可以作为设计文档的一部分提交。论文LW的写作逻辑上面提到过核心是不要写成代码说明书而要写成“分析-设计-实现-测试”的完整链路。每个核心功能的标题下面先写业务规则和流程再贴核心代码片段最后附上运行截图。测试部分建议用表格形式写功能测试用例比如“输入学生提交离校申请预期结果数据库插入状态为0的记录教师端待办列表新增一条实际结果通过”。这样的用例表写十几条测试章节就有了充足的内容支撑。6. 我在复现这类毕设时踩过的坑和总结6.1 Spring Boot版本和JDK版本的匹配问题这是最常见也最要命的一个坑。Spring Boot 3.x版本强制要求JDK 17及以上而很多学校的课程实验环境还停留在JDK 8。如果你的电脑装的是JDK 8却下载了最新的Spring Boot 3.x依赖启动时会直接报错报错信息看起来像是“UnsupportedClassVersionError”。所以开始做项目前第一件事确认你的JDK版本和Spring Boot版本匹配JDK版本推荐的Spring Boot版本JDK 82.6.x 或 2.7.xJDK 112.7.x 或 3.0.xJDK 173.x很多拿来即用的毕设源码为了照顾学生环境大概率用的是Spring Boot 2.x。如果你拿到源码后手动升过级一定要注意MyBatis-Plus、JWT这些依赖库的版本也要同步调整否则会出现一堆莫名其妙的类找不到错误。6.2 小程序获取不到微信用户信息的典型原因标题相关热搜词里有一条“小程序获取登录后的微信用户失败”这是很多同学的痛点。这里面的原因可能有好几层。第一层是接口调用失败。小程序端用wx.login()获取code时需要确保appid配置正确。项目里的project.config.json文件中的appid字段如果用测试号或者别人的appid调用微信接口时会返回错误码。你在真机预览时必须使用自己在微信公众平台注册的小程序appid。第二层是获取用户昵称头像的接口变了。早期大家习惯用wx.getUserInfo()直接弹出授权框获取用户头像昵称但这个接口现在基本不可用了。微信调整了策略开发者必须使用button组件的open-typechooseAvatar来引导用户主动选择头像昵称通过input组件让用户自己填写。所以如果你从老项目里扒代码会发现头像昵称获取逻辑完全失效。第三层是openid关联错了。用户首次登录时后端用openid创建账号但如果学生后续完善身份信息时填写的学号和已有的学生档案不匹配会导致数据关联不上。建议的做法是管理员在后台维护一份学生档案小程序端登录后填写学号姓名后端用这两个字段精确匹配学生表匹配成功才完成绑定。绑定成功后把user_id回写到student表后续所有操作都用这个user_id来关联。6.3 联调阶段因为接口字段命名不一致反复返工前端小程序习惯使用驼峰命名法比如leaveDate而后端Java实体的字段如果是leave_date数据库下划线命名风格在返回给前端时如果没有配置驼峰转换前端拿到的就是leave_date而不是leaveDate。字段一旦对不上前端取值就是undefined页面渲染不出来人会陷入疯狂排查的循环。解决这个问题有几个办法。最简单的是后端在返回JSON时使用JsonProperty注解显式指定字段名。更推荐的是在项目配置里打开MyBatis-Plus或Jackson的下划线转驼峰配置让框架自动完成转换。这样数据库字段保持leave_dateJava实体用leaveDate前端直接用leaveDate取值各层语义一致。前端这边也需要一个约定封装一个统一的request工具所有请求都走这一个方法。这样当后端返回401时前端可以统一跳转登录页当后端返回500时前端统一弹出“服务器异常请稍后重试”。联调阶段能把后端抛出的异常堆栈直接打印在控制台排查问题会快非常多。6.4 论文LW写作和代码实现脱节的问题我见过很多学生代码写得不错但论文里完全看不出来就是大量堆砌“系统采用Spring Boot框架具有简单易用、快速开发的优点”这样的套话。答辩时老师问一个具体实现细节他答不上来因为论文里根本没有涉及具体实现全是框架介绍。正确的做法是论文每一章都要和代码对应起来。概要设计里的功能结构图应该是你代码中实际存在的模块详细设计里的表结构应该和数据库的建表语句一致系统实现里的截图应该是你程序真实运行的界面。你可以把核心流程的时序图、关键接口的入参出参示例、状态流转的说明写到论文里这样的论文不用堆字数内容自然就充实了。我的个人经验是先把系统做完再做论文。系统做完了每一步都是你实际走过的路写起来自然行云流水。反过来先写论文再写代码最后代码大概率会跟论文对不上那种感觉才是真的痛苦。6.5 最后的几点经验总结这个毕设题目拿下它其实只需要按顺序走好这几步先把需求边界想清楚确定角色和功能再定技术栈Spring Boot 小程序是稳妥组合然后设计数据库核心是离校登记表和审批日志表接着实现接口重点打通登录、登记、审批这三条链路最后部署上线把演示视频和论文材料补齐。每一步之间都有自然的依赖关系前面扎实了后面就顺畅。我在帮别人看代码时最怕看到的状态是学生手里攥着一整套源码但完全讲不清楚每一层在干什么。这类题目在答辩时老师最常问的就是“前端调用哪个接口、后端怎么处理、数据存哪张表”你必须对这三个问题形成条件反射。如果你现在是拿到源码还处于一头雾水的状态别急着改代码先把自己当成一个用户把应用完整跑一遍感受一下数据是怎么流转的然后看数据库表结构理清每张表的作用最后再结合我这篇文章讲的实现链路去读代码你会发现源码其实并不神秘。等你能跟别人解释清楚“这个系统的审批流是怎么实现的”你离顺利通过答辩就不远了。