企业官网建设流程全解析

每年这个时间点，总有同学拿着“基于Java+SSM+Flask学生考勤管理系统”这类课题来问我：源码拿到了，论文（LW）也有，调试文档也有，但不知道从哪里下手，更不知道答辩的时候老师会问什么。

说实话，这种“双框架混合”的考勤管理系统，在计算机相关专业的毕业设计里相当常见，而且是一个性价比很高的课题。它踩着校园信息化管理的刚需，又同时展示了Java主流的SSM业务开发能力和Python生态的灵活扩展能力。比起那些纯增删改查的管理系统，它的技术纵深明显更够用。这篇文章我就基于这类课题的普遍形态，把整个系统从模块设计、技术分工、核心实现，到部署排错、论文编排，完整地拆给你看。无论你是刚拿到源码还没打开IDEA，还是已经在调试路上卡了两天，这篇文章都能帮你把思路彻底理顺。

1. 为什么SSM+Flask这种“双框架”结构是考勤系统课题里的常见高分方案

1.1 不是你想象的那种“炫技”：双框架背后是明确的分工逻辑

很多人第一次看到SSM加Flask会有点懵：一个系统为什么要用两套后端框架？是不是故意堆技术？其实完全不是。Java配合SSM（Spring、SpringMVC、MyBatis）非常擅长做结构化的业务系统：人员管理、课表管理、考勤记录、权限控制、统计分析这一整套稳定业务，用SSM写起来代码组织清晰、事务处理可靠。

但考勤系统往往还有一些“偏算法”或“偏数据处理”的模块，比如学生上课前的无感签到（人脸识别）、批量导入Excel解析、生成复杂的考勤统计图表数据、定时推送出勤异常通知。这些模块如果硬塞进Java代码里，不是不行，而是很费劲。Python生态里有现成的OpenCV、numpy、pandas、APScheduler、Flask这类库，几行代码就能解决Java里要写一大坨工具类的问题。于是常见的高分设计就是：SSM作为主站点负责核心业务，Flask作为辅助服务负责算法和数据处理类功能，两者通过HTTP接口或共库协作。

1.2 同类纯SSM课题和这个方案的差距到底在哪

如果你对比过“基于SSM的考勤管理系统”和“基于SSM+Flask的考勤管理系统”，很快就会发现后者的演示层次完全不同。纯SSM版本大概率是：管理员录入学生、录入课程、学生登录后点击“签到”按钮，教师查看表格。所有功能都很“正”，但缺少让人眼前一亮的点。

而加入Flask之后，常见的加分项就出来了：

• 学生签到时可以上传一张现场照片，Python端做人脸比对或活体检测，比对通过才允许签到；
• 教师端可以自动生成考勤异常报表，Flask定时任务每天早上九点统计前一天缺勤名单；
• 系统可以对接企业微信或公众号，Flask把考勤异常推送给辅导员。

这些功能用Java也能写，但“渲染”出来的答辩效果完全不一样。老师看到代码里既有SSM的Controller、Service、Mapper三层架构，又有Python的Flask接口和算法脚本，第一反应是这人懂工程整合，而不是只会照着教程抄。

1.3 这套系统到底适合谁来研究、能解决什么问题

如果你是这几类人，这套系统的研究价值很大：

• 应届毕业生准备答辩，需要一篇“有业务场景、有前后端、有混合框架”的毕业设计；
• 在读学生做课程设计，想找一个可以直接跑通、又能讲清原理的完整项目；
• 刚入行程序员想理解“Java业务系统如何和Python服务集成”，这是一个很好的低成本案例。

它解决的问题也很明确：通过信息化手段替代人工点名，把学生出勤数据沉淀下来，自动算出勤率、迟到率、缺勤名单，减少辅导员和任课老师的重复统计工作。只要有高校背景、有班级课程概念、有签到需求，这个系统就能直接落地。

2. 先把需求地图画清楚：一类系统三类角色的任务边界

2.1 管理员、教师、学生的权限边界不是随便划分的

我之前带过一个同学，他的第一版代码里所有人都能查所有人的考勤记录，当时我就让他停下来先把角色权限画清楚。一个考勤系统，角色边界必须非常清晰：

• 管理员负责基础数据维护：院系、班级、课程、教师账号、学生账号的增删改查，还有全局考勤记录的查看与统计。管理员不参与签到业务本身。
• 教师是考勤的主要发起者，他需要看到自己的课程列表，在上课前发起签到，查看这次签到的实时结果，还能对请假申请进行审批。
• 学生是考勤的主要被执行者，登录后能看到自己今天有哪些课，点击签到，查看自己的历史出勤记录和出勤率，提交请假申请。

这三角色对应到代码里，就是三套菜单权限、三套前端页面、三套拦截器白名单。常见的做法是在用户表加一个role字段，1管理员、2教师、3学生，后端拦截器里用Session或Redis存当前用户身份，每次请求判断可访问路径。

2.2 功能模块清单别照抄网上，要能回答“谁在什么时候做什么事”

我在写正常功能清单前，习惯先写一份“角色操作说明书”，这样功能点才不会遗漏。比如教师的操作链路是：登录 -> 查看我的课程 -> 点击某门课程 -> 发起签到（生成签到码） -> 实时查看已签到人数 -> 查看未签到学生名单 -> 处理学生请假申请。

对应到系统的功能模块，大概是这些：

• 用户认证模块：登录、注销、修改密码、Session校验；
• 院系班级管理：院系信息维护、班级信息维护、学生分班；
• 课程管理：课程信息、教师任课关系、班级选课关系；
• 考勤发起与签到：教师发起签到、系统生成签到口令或二维码、学生输入口令签到或扫码签到；
• 请假管理：学生提交请假、教师审批、请假记录关联到考勤状态；
• 考勤统计：课程维度出勤率、班级维度出勤率、个人出勤明细、异常名单汇总。

如果还有Flask辅助服务，那么可以额外列一个“辅助功能”模块：人脸识别签到、Excel批量导入、定时推送、图表数据接口。但有一点要提醒：这些扩展功能选一两个做深就行，贪多嚼不烂，答辩时你根本讲不完。

2.3 一次完整的课堂签到是如何走完整个数据链路的

把一次签到的流程走通，比背十个接口都有用。我以一个最常见的场景“教师发起限时签到”为例：

1. 教师登录系统，进入“我的课程”，点击某课程后的“发起签到”按钮；
2. 主系统（SSM）在考勤表里插入一条记录，状态为“进行中”，同时生成一个四位随机码，保存到该记录上；
3. 前端页面拿到签到码后，可以显示在教室大屏，也可以通过接口推给Flask服务，由Flask生成一个带课程标识的二维码；
4. 学生打开系统，点击“签到”，输入口令（或扫码），提交自己的当前位置和签到时间；
5. 主系统收到请求后，先校验口令是否正确、签到时间是否在有效期内、当前用户是否属于该课程班级，这些校验全部通过才写入签到明细；
6. 教师端页面通过定时轮询或WebSocket，刷新出已签到列表和未签到列表；
7. 教师点击“结束签到”后，系统把未签到学生自动标记为缺勤，同时把这次考勤汇总写入统计表。

这里最关键的是第5步的校验顺序：口令校验、时间校验、班级归属校验。顺序写反了，就会出现“口令正确但人不对”也能签上的事故。

2.4 出勤率和异常名单的计算口径必须在文档里写清楚

很多系统的统计模块被质疑“数据不对”，问题往往出在计算口径上。什么叫出勤率？是“实际签到人数 / 班级总人数”，还是“实际签到人数 / 应到人数”？请假算不算出勤？迟到算不算出勤？这些都要在需求阶段定死，否则前后端显示永远对不上。

我建议的统一口径是：

• 应到人数= 该班级学生总数 - 请假审批通过人数；
• 实到人数= 成功签到的人数（迟到也算实到）；
• 出勤率= 实到人数 / 应到人数，保留两位小数；
• 缺勤率= 缺勤人数 / 应到人数；
• 迟到率= 迟到人数 / 应到人数。

把这些公式写进论文的需求分析章节，评委老师一看你的数据定义是严谨的，印象分直接上去。

3. SSM主站点的核心实现：表结构、签到判定和权限控制的落地细节

3.1 考勤系统的表结构设计，几张核心表要一次设计到位

数据库设计好坏直接决定后续写代码是舒服还是难受。考勤系统最核心的几张表，我建议你闭着眼睛都能画出来：

• sys_user：用户主表，字段包括id、username、password、real_name、role、status，三个角色统一存在这张表里，不要再拆三张表；
• student_info：学生信息表，字段包括id、user_id、student_no、class_id、phone，关联用户表；
• teacher_info：教师信息表，字段包括id、user_id、teacher_no、department_id、title；
• course：课程表，字段包括id、course_name、teacher_id、credit、weeks；
• course_class：课程班级关联表，这是多对多的典型拆分，记录某门课对哪些班级开放；
• attendance_session：考勤批次表，记录教师发起的某次签到，字段包括id、course_id、teacher_id、start_time、end_time、status、sign_code；
• attendance_record：考勤明细表，记录每名学生的签到结果，字段包括id、session_id、student_id、sign_time、status（正常/迟到/缺勤/请假）；
• leave_apply：请假申请表，字段包括id、student_id、course_id、reason、start_time、end_time、status。

这里有个容易踩的坑：很多人把考勤结果直接设计成“每个学生对应课程的一条记录”，结果每天一节课就生成几千条预置记录，数据非常冗余。正确的做法是“按考勤批次生成成绩”，教师不发起点名，学生就不产生考勤记录，等查缺勤时用“批次 + 班级学生”做补集运算。

3.2 “正常、迟到、缺勤”不是写死状态，而是计算出来的

签到判定可以说是整个系统最容易出逻辑错误的地方。一个常见做法是：教师发起签到时，设定一个有效签到时间段，比如上课前5分钟开始，上课后10分钟结束。那系统怎么判断学生是迟到还是正常？

我推荐的判定顺序是：

• 学生提交签到后，先判断该签到批次是否处于进行中状态，如果不是，拒绝签到；
• 然后获取当前时间，和批次允许的迟到截止时间比较；
• 如果当前时间小于等于迟到截止时间，状态为“正常”；
• 如果大于迟到截止时间且小于批次结束时间，状态为“迟到”；
• 批次结束后仍未签到的学生，由定时任务统一标记为“缺勤”；
• 审批通过的请假记录，在生成缺勤名单时自动排除，并单独标记为“请假”。

这个逻辑看起来简单，但代码实现时要特别注意：状态必须在签到写入时就确定，不要留到统计时再反推。因为统计时反推涉及大量时间比较和状态转换，非常容易产生“数据漂移”。

3.3 MyBatis关联查询和事务边界怎么控制才能不崩

SSM项目里，Controller层要薄，Service层和Mapper层才是核心。写考勤系统时，几个典型场景的事务边界一定要把握好：

第一个是“发起签到”：要插入考勤批次记录，同时更新课程的最近签到状态。如果插入成功但状态更新失败，就会出现“发起不了签到但产生了孤儿批次”，所以这两个操作必须在同一个事务方法里。

第二个是“学生提交签到”：插入考勤明细成功后，还要更新统计缓存表里的已签人数。明细保存成功但统计失败，教师端显示人数就不对。也是一个事务。

MyBatis这块我建议大家多写几个自定义SQL，不要全依赖自动生成的Mapper。比如“查询某门课程的缺勤名单”，核心逻辑是：

SELECT si.student_no, si.real_name FROM student_info si WHERE si.class_id = (SELECT class_id FROM course_class WHERE course_id = #{courseId}) AND si.id NOT IN ( SELECT student_id FROM attendance_record WHERE session_id = #{sessionId} )

这种“差集”查询在论文的详细设计章节里写出来，比贴一百行Java代码更有说服力。

3.4 登录拦截和权限控制，不用框架也能写干净

虽然SpringMVC可以配合Shiro或Spring Security，但考勤系统这种规模，自己写拦截器其实更轻量、更好讲。常见实现是：

• 用户登录成功后，把user对象和role写进Session；
• 写一个LoginInterceptor，在preHandle里判断请求路径，如果是放过路径（login、静态资源、Flask回调），直接放行；
• 其他请求必须校验Session登录状态，未登录跳转到登录页；
• 再写一个RoleInterceptor，根据请求前缀判断权限：/admin/** 需要管理员，/teacher/** 需要教师，/student/** 需要学生。

这种设计在论文里也好写：自定义拦截器实现细粒度权限控制。比引入一个你其实说不清原理的安全框架要踏实得多。

4. Flask辅助服务到底做什么：常见分工方案与两种对接方式的取舍

4.1 我见过最常见的方案：把“脏活”和“定时活”交给Python

很多人拿到源码第一眼会疑惑：Flask服务在哪？其实这类课题里，Flask端的角色主要有三种常见形态，你可以对照自己的源码看看它属于哪一种：

第一种是人脸识别签到服务。学生签到时上传一张照片，Java把图片转成Base64传给Flask接口，Flask接收后调用OpenCV或人脸识别库提取特征，和库里预存的人脸特征做比对，返回相似度和是否通过。这个流程用Java写会非常痛苦，但在Python里是几行的事情。

第二种是Excel批量导入服务。管理员要一次性导入几百个学生，Java端写POI也能做，但很多课题为了省事，把Excel上传到Flask，Flask用pandas清洗数据后返回JSON，Java拿到JSON再批量写入数据库。

第三种是定时任务服务。每天凌晨，Flask用APScheduler定时执行统计脚本，查出前一天缺勤学生名单，然后通过数据库直连或HTTP回调，把结果同步给Java端。

我特别建议你自己动手在Flask端加一个“定时统计缺勤并生成Excel报告”的功能。代码量不大，但演示效果好：前一天学生在系统里的缺勤记录，第二天早上自动生成一份报告，这已经是很完整的“数据自动化”闭环了。

4.2 SSM和Flask联调用HTTP还是共库，很多人没搞清楚利弊

两种对接方式各有适用场景，别混着用。

• HTTP + JSON接口：Java端通过RestTemplate或HttpClient调用Flask的接口。优点是解耦干净，Flask不直接碰数据库，Java业务逻辑不受影响；缺点是跨语言联调时要处理跨域、超时、序列化问题。
• 共享数据库：Flask服务直接配置同一个MySQL数据源，读取和写入Java的表。优点是实现简单、效率高，不用写接口；缺点是数据库耦合严重，两边对同一张表操作时容易产生锁冲突和逻辑不一致。

我的建议是：实时性要求高的场景（人脸识别比对、照片处理）用HTTP接口；批量数据处理场景（定时统计、Excel解析）用共享数据库。理由很简单：人脸比对是瞬时请求，走接口让Java按需调用更灵活；定时统计是离线任务，写个Python脚本直连库去算，比来回调接口稳得多。

4.3 Flask端环境搭建的几个关键坑位

Flask服务本身很简单，但环境问题能让新手卡一整天。我这里提前把高频坑位列一下：

• 虚拟环境：一定给项目建独立的虚拟环境，不要用系统的Python环境，否则别人拿到你的依赖列表都安装不到一起；
• 依赖锁定：用requirements.txt锁版本，尤其是opencv-python、pandas、flask这些包，版本变了API差异很大；
• 跨域问题：如果学生端页面是纯静态页面或Vue项目，Flask接口必须配置CORS，否则浏览器里请求会被拦；
• 端口别撞车：Flask默认5000端口，如果本机被占用了，你要改端口并更新Java端配置。

给一个最小可用的Flask接口模板：

from flask import Flask, request, jsonify from flask_cors import CORS app = Flask(__name__) CORS(app) @app.route("/api/health", methods=["GET"]) def health(): return jsonify({"code": 200, "msg": "ok"}) if __name__ == "__main__": app.run(host="0.0.0.0", port=5000)

5. 从部署到联调的踩坑实录：环境、数据库、跨域和路由全套问题

5.1 JDK版本、Tomcat版本和框架版本不匹配，第一道坎

SSM项目最常用的组合是JDK 8、Tomcat 8、Maven 3.x、Spring 5.x。我真见过有人装了个JDK 17，启动Tomcat时直接报非法反射访问，项目根本跑不起来。拿到源码后先看pom.xml里的Spring版本和JDK版本的兼容性，如果不知道为什么报错，就一套装成经典版本：

• JDK 1.8
• Maven 3.6.3
• Tomcat 8.5
• MySQL 5.7 或 8.0

很多老项目用的还是web.xml配置方式，你必须确认项目是war包部署到Tomcat的webapps下，而不是用Maven插件直接run。如果用IDEA部署，建议配置Tomcat的Deployment选项，把war包部署上去，同时把Application context设为/，避免访问路径多一层项目名。

5.2 MySQL版本差异导致的那几个“莫名其妙”的报错

数据库连接报错在调试阶段比例非常高，尤其是MySQL 8出来之后。常见症状和原因：

• “Public Key Retrieval is not allowed”——MySQL 8默认使用caching_sha2_password插件，驱动连接时需要设置allowPublicKeyRetrieval=true，并在url里加useSSL=false；
• “Unknown database”或者乱码——创建库时要明确设置为utf8mb4字符集；
• ClassNotFoundException——检查驱动名是com.mysql.jdbc.Driver还是com.mysql.cj.jdbc.Driver，MySQL 8必须用后者。

我的统一解决方案是写进调试文档里：

jdbc:mysql://localhost:3306/attendance?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai&allowPublicKeyRetrieval=true driver=com.mysql.cj.jdbc.Driver

我建议拿到源码的第一天就把数据库初始化脚本跑通：先建库、再导SQL、最后改配置文件，顺序不能乱。很多人卡在启动阶段，其实只是库里没表或者账号密码不对。

5.3 Tomcat启动后页面404、接口500、资源加载不出来怎么办

这类问题排查有一个标准路径：

1. 启动Tomcat后，先看日志，有没有异常堆栈；
2. 输入最基础的“项目名/”看是否访问到登录页，如果404，说明部署上下文不对，检查IDEA Deployment里的Application context；
3. 如果页面能开但样式全乱，说明静态资源路径不对，检查DispatcherServlet是否拦截了.html、.css、.js；
4. 接口500时，看异常是数据库连接问题、空指针问题还是Mapper扫描不到，基本都能从栈顶看到原因；
5. 控制台没报错但功能不对，就要看有没有接口被拦截器拦掉了。

这里有个经验：排查前端页面问题时，把浏览器F12的标准用途用起来。Network面板看到404是路径问题，看到500是后端问题，看到跨域报错是接口配置问题，看到加载超时多半是WebSocket或轮询接口卡住。定位到方向再动手，不要盲改。

5.4 联调阶段的高频顺序问题：Java发请求给Flask为什么总是失败

SSM调用Flask接口失败，最常见的几个原因：

• Flask服务没启动——这个不用解释，但很多人真的忘了；
• IP和端口不对——Java配置里写localhost:5000，但你的Flask在另一台机器上，或者端口改了，自然不通；
• 超时时间太短——人脸识别这种接口可能要两三秒，RestTemplate默认超时可能不够，要手动设置；
• 跨域混淆——跨域是指浏览器端跨域，Java后端调Flask不存在跨域问题，如果调用失败，优先看是不是连接和接口地址问题。

给个建议：Java调Flask前，先用浏览器直接访问Flask的接口地址，看能不能返回JSON。接口通不通先确认，再排查Java代码里的请求参数和返回解析。

6. 论文写作和答辩演示：LW、调试文档和演示话术怎么组织

6.1 毕业论文的章节结构，怎么和系统代码一一对应

我把这类课题最舒服的论文结构给一个参考，每个章节对应项目里的什么东西，心里要有数：

• 绪论：写考勤管理的背景意义、国内外现状。现状部分不要从网上抄一堆没用的，聚焦“传统人工点名效率低、数据难沉淀”这一个核心问题；
• 需求分析：把三角色功能用例图、业务流程图画出来，重点把“出勤率计算口径”写清楚，这是最容易体现设计能力的地方；
• 总体设计：画系统架构图，明确SSM主服务层、Flask辅助服务层、MySQL存储层；画模块功能结构图；
• 详细设计：按“数据库设计 + 核心模块实现”展开。数据库设计要贴表结构说明；核心模块挑“发起签到、学生签到、考勤统计”三个写实现流程，配合核心代码；
• 系统测试：写功能测试用例表，覆盖三角色核心操作，再写性能测试或兼容性测试。

我记得一个特别加分的小细节：论文里在架构图上区分开“学生端浏览器”和“教师端浏览器”，把HTTP请求流向画清楚，能让老师一眼看出你对整个系统是通盘掌握的。

6.2 调试文档不是流水账，只写三类内容就够了

拿到源码附带的调试文档模板时，很多人的第一反应是抄一遍部署步骤。我觉得调试文档的价值应该体现在这三类内容上：

• 环境搭建清单：JDK、Maven、Tomcat、MySQL、Python版本，以及每个版本对应的配置文件位置；
• 启动步骤顺序：先启动MySQL、导入SQL，再启动Flask服务，最后启动Tomcat。这个顺序一定要写，顺序错了系统就起不来；
• 常见问题与解决方案表：把“端口被占用”“数据库连接失败”“登录验证码不显示”“Flask接口报404”这些问题整理成一张表，问题、原因、解决方案各一列。

我建议你调试的过程中每踩到一个坑，就顺手把问题和解决办法写进调试文档，而不是最后几天集中补。这样文档才真实，而且你答辩时遇到类似问题也能脱口而出。

6.3 答辩环节被问到最多的三个问题，准备好再说

根据我熟悉的答辩场景，这类课题的高频提问基本是固定的：

第一个：“为什么引入Flask？SSM不是已经可以完成所有功能吗？”

回答思路：SSM负责核心业务稳定开发，Flask负责对时效性要求高、依赖Python生态的功能，比如定时统计、数据处理。这不是为了加技术而加技术，而是让合适的工具干合适的活。这个回答要练熟，因为几乎必问。

第二个：“这个系统相比传统人工点名，核心优势是什么？”

回答思路：双击体现在三个层面——实时性（扫码/口令签到即刻出结果）、数据化（出勤率自动统计）、自动化（缺勤名单定时同步）。不要讲“提高了效率”这种空话，要落到具体数据上。

第三个：“你的签到记录如何防止伪造？比如学生让别人代签？”

回答思路：如果是口令签到，可以直接说“口令限定时间内有效，且每次发起随机生成，同时签到时记录IP和设备信息，后续可追溯”；如果有人脸识别，这就是你最好的亮点。没有防伪手段也没关系，已经发生的风险说明白就行。

6.4 演示Demo的顺序和话术，比你想的更重要

演示环节最大的忌讳是“上来就登录管理员账号，然后一顿乱点菜单”。你应该按角色流程来演示：

1. 先用管理员身份登录，给学生和教师建账号、建课程、分班级，展示基础数据从无到有的过程；
2. 再切换教师账号，进入课程、发起一个签到，当着评委的面生成签到码；
3. 切换到几个学生账号，依次签到，故意让其中一个在截止时间后签到，造出“迟到”数据；
4. 回到教师端，展示实时已签/未签列表，结束签到；
5. 最后切到统计页面，把这次考勤的出勤率、迟到率展示出来，再展示一张缺勤名单Excel生成过程。

这个流程走下来，系统和论文里的需求、设计、测试是能对上的。我发现很多同学演示到第三步就结束了，评委看不到统计模块，自然觉得系统只有“记录”没有“分析”。

7. 我一直建议的扩展方向和技术体会

7.1 如果你时间充裕，优先扩展“移动端签到”而不是堆新功能

考勤系统这类项目，评委大概率会问“未来怎么扩展”。我的建议是不要在答辩前临时加一堆新功能，而是准备好扩展方向，用嘴说清楚就够了，比如：

• 接入小程序：学生扫码签到用小程序实现，比浏览器体验好，可以作为“移动端签到”模块写进论文展望；
• 地理位置限制：签到必须位于教室附近，通过GPS或蓝牙Beacon实现；
• 无感考勤：结合人脸识别摄像头，学生进教室自动完成考勤，这是目前比较前沿的方向。

从我的实际经验看，一个能完整跑通“发起签到-学生签到-自动统计-异常报告”的SSM+Flask系统，已经覆盖了毕业设计要求的全部核心点。你要做的不是功能做多，而是把已有链路跑通、跑顺、跑出演示效果。

7.2 三件我踩过坑后才明白的小事

第一，时间处理统一用LocalDateTime，不要混合使用Date和String，前后端传输统一用格式化的字符串，否则统计迟到的边界条件会出各种莫名其妙的问题。

第二，签到口令保存到数据库时不要明文比对，至少做一层加盐哈希，虽然考勤系统安全要求不高，但这在论文里可以写进“安全性设计”，算一个加分点。

第三，所有列表接口务必分页，班级学生列表几百条数据不分页也能出，但考勤记录一旦跑一个学期，不分页的接口必然卡死演示环节。分页逻辑本身也得是后端完成的，不要真的把全部数据查到前端再截断。

7.3 最后，拿到源码后的正确打开方式

我特别不建议你拿到源码直接跑起来就开始改改改。正确顺序应该是：先把数据库脚本执行成功，再把项目启动起来，然后按角色走一遍所有功能；接着对着源码画出模块图和数据表关系；最后才动手调整功能或美化界面。这套流程下来，你大概需要两到三天。但它能保证你对系统的每一个细节都心中有数，而“心中有数”这四个字，才是你毕业答辩最稳的底气。