每年毕业设计开题季我都要帮好几拨学生审同一类题目——基于JAVA的企业人事管理系统。这个题几乎成了信息管理类毕设的常青树它既有员工信息这种典型的增删改查页面又有考勤、薪资这类带一点业务规则的计算难度适中评委也都听得懂。但恰恰因为太常见很多人的成品反而平平无奇模块堆了一堆数据库几张表随便建文档和PPT明显是凑字数。这篇文章就围绕基于JAVA的企业人事管理系统的设计与实现这个完整课题讲讲我从需求拆分、技术选型、数据库设计、核心代码实现到设计文档、答辩PPT、最后部署上线的全套做法。适合正在做这个题目的学生也适合想快速搭一套企业内部门户人事模块的初级开发者。1. 先把人事部的活儿捋清楚模块边界与需求取舍1.1 从人事管理四个字反推业务场景很多人拿到这个题目第一反应是打开搜索引擎找人力资源系统功能清单结果搜出来一堆HR专业软件的功能罗列招聘、培训、绩效、社保、公积金、劳动合同、人才测评……然后一个不落地写进需求文档。这是最典型的失败开局。人事管理系统的核心服务对象不是HR专业理论而是企业内部最日常、最高频的那几条业务线。我习惯先画一张人事部一周工作清单再从中圈出适合用代码自动化的事情员工入职、转正、调动、离职登记部门与岗位的调整记录每天的上下班打卡与考勤统计月底基于考勤结果算工资发布公司通知、员工查看工资条给不同角色分配不同的操作权限这几件事对应的功能模块非常清晰。做一个完整的毕设或部门级小系统真正要写代码的模块就是下面这些模块核心功能点实现难度优先级员工管理入职新增、信息修改、查询、离职标记、Excel导出低必做部门管理部门新增、编辑、层级关系维护低必做用户与权限登录、注销、角色区分、菜单权限中必做考勤管理每日打卡、按月份统计出勤情况中建议做薪资管理薪资项配置、月度工资计算、工资条查询中高建议做公告管理公告发布、列表查看低可选招聘、培训、绩效这三个模块我强烈建议不要加进毕设。原因很简单招聘涉及简历解析、面试流程、Offer发放业务链路长培训涉及课程资源、学习进度跟踪绩效更是每个公司考核规则都不一样很难设计出一套让评委信服的通用逻辑。模块加多了答辩时每个都只能讲两句增删改查反而暴露深度不够。宁可少而精把考勤和薪资这两个带计算逻辑的模块做扎实这才是能跟评委聊起来的亮点。1.2 三种角色看到的是三个不同的系统确定模块之后第二步是分清角色。人事系统里最常见的角色就三种系统管理员通常就是人事专员、部门经理、普通员工。管理员维护员工档案、部门信息、考勤标准、薪资规则、发布公告拥有几乎全部权限。部门经理查看本部门员工花名册审批简单的请假或调动申请如果做审批流。普通员工查看自己的个人信息、每日打卡、查看自己的考勤统计和工资条。这个角色划分直接决定了后面数据库里的用户表、角色表以及菜单权限设计。一个很实用的检查方法把每个角色打开系统后第一眼看到的页面写下来。管理员是数据总览仪表盘经理是部门员工列表员工是个人考勤卡片。如果系统首页能做到因角色而异演示效果会明显好过所有人登录后看到同一张页面。1.3 需求文档里的用例数量控制在20个以内写需求分析章节时不用追求用例数量多核心用例控制在15-20个就足够。我给一个可以直接抄的清单员工登录员工退出管理员新增员工管理员编辑员工信息管理员做离职处理员工/经理分页查询员工列表管理员新增部门管理员调整员工所属部门员工每日上班打卡员工每日下班打卡管理员按月份查看考勤汇总系统自动计算月度工资员工查看自己的工资条管理员发布公告员工查看公告列表这些用例还有第二个用途它们就是答辩现场的功能演示清单。评委提问时照着自己列表里的功能一个一个演示过去流程一定不会乱。2. 技术栈不是越新越好为什么我选Spring Boot MyBatis撑起这套系统2.1 从JSP/Servlet到Spring Boot一次开发体验的质变很多学校课程还在用JSPServlet教JavaWeb但做实际项目时我更推荐直接上Spring Boot。不是否定基础课的教学价值而是效率差距太明显。用Servlet写一个员工查询要写doGet、doPost、处理中文乱码、手动拼接HTML、管理Session光是重复代码就能占掉一半篇幅。Spring Boot把内嵌Tomcat、自动配置、依赖管理这些脏活累活全干了一个main方法就能启动整个Web应用。对毕业设计和课程设计场景来说最重要的评价指标不是技术新旧而是能否稳定跑通并讲清楚。Spring Boot已经成了Java后端招聘的默认门槛答辩时评委听到Spring Boot第一反应是认可而不是质疑为什么不用更冷门的东西。如果你的指导老师要求体现从JavaWeb到框架的学习过程可以在系统设计章节写一段演进说明但代码实现直接用Spring Boot别跟自己的时间过不去。2.2 MyBatis vs JPA复杂联表查询面前SQL可控性更重要ORM框架我推荐MyBatis进阶一点用MyBatis-Plus。人事系统的查询有一个特点大量联表。员工要关联部门、考勤要关联员工、工资要关联员工和考勤如果加上部门层级SQL里还要处理父子关系。MyBatis把SQL写在XML里写多长的联表查询都直观可控性能出问题也知道去哪优化。JPA虽然能省掉一部分CRUD代码但一旦遇到多表聚合查询不是写Query就是走Specification调试起来让人头大对初学者并不友好。MyBatis-Plus更是把快做到了极致。继承一个BaseMapperT单表增删改查方法全都自带不用写一行XML。它还有一个实用功能可以根据实体类自动生成建表SQL这对快速搭建演示项目非常方便。设计好Java实体类字段数据库表结构跟着就有了文档里的表结构说明也容易保持一致。2.3 前端走模板引擎还是前后端分离我建议一个人开发就选Thymeleaf两种路线都有人用。选VueSpring Boot前后端分离页面效果确实更现代但代价是要处理跨域、要单独跑前端工程、要写接口文档工作量至少多三分之一。一个人做毕设时间本来就不宽裕我更建议用Spring Boot Thymeleaf模板引擎。Thymeleaf的优势是后端渲染HTML数据从Controller通过Model传到页面跟原来的JSP思路类似学习曲线平缓。而且编译产物就是一个jar包页面静态资源全在jar里部署时不用考虑Nginx托管前端文件的问题。评委要演示一个java -jar命令全部搞定非常省心。前端样式不用自己从零写直接引Bootstrap或AdminLTE这类开源后台模板。我的原则是后端逻辑是核心前端只要干净整齐、布局合理就足够拿一个不错的印象分。2.4 锁住版本号比什么优化都实在这套系统的依赖版本我用的是经过验证的组合直接抄就行组件版本说明JDK1.8 或 11Spring Boot 2.7 完全兼容Spring Boot2.7.x稳定且资料多别急着上3.xMyBatis-Plus3.5.x自带分页插件和代码生成器MySQL8.0驱动用com.mysql.cj.jdbc.DriverDruid1.2.x阿里连接池监控方便Thymeleaf3.0.x配合Spring Boot 2.7自动管理版本Lombok最新减少实体类getter/setter代码这里特别提醒一句Spring Boot 3.x 最低要求JDK 17如果电脑上环境变量配的是JDK 8启动会直接报错。为了稳毕业设计阶段老老实实用2.7版本网上教程也最多遇到问题好查。3. 数据库设计决定了系统的天花板一张ER图背后的字段博弈3.1 最少8张表撑起一个完整可演示的人事系统数据库设计是评委最爱深挖的部分也是整个系统能不能讲出花来的分水岭。一个合格的人事管理系统最少要有下面这些表表名存储内容关键关联dept部门主键id被employee引用employee员工基本信息dept_id关联deptuser登录账号emp_id关联employeerole_id关联rolerole角色提供角色编码attendance每日考勤emp_id关联employeesalary月度工资emp_id关联employeesalary_config薪资项配置存储基本工资、岗位工资基数notice公告发布人关联user核心表employee的表结构可以这样设计CREATE TABLE employee ( id bigint NOT NULL AUTO_INCREMENT COMMENT 主键, emp_no varchar(20) NOT NULL COMMENT 工号, name varchar(50) NOT NULL COMMENT 姓名, gender tinyint DEFAULT NULL COMMENT 性别 1男 0女, birth_date date DEFAULT NULL COMMENT 出生日期, id_card varchar(18) DEFAULT NULL COMMENT 身份证号, phone varchar(11) DEFAULT NULL COMMENT 手机号, email varchar(50) DEFAULT NULL COMMENT 邮箱, dept_id bigint DEFAULT NULL COMMENT 部门id, position varchar(50) DEFAULT NULL COMMENT 岗位, hire_date date DEFAULT NULL COMMENT 入职日期, emp_status tinyint DEFAULT 1 COMMENT 状态 1在职 0离职 2试用, remark varchar(255) DEFAULT NULL COMMENT 备注, deleted tinyint DEFAULT 0 COMMENT 逻辑删除 0未删 1已删, create_time datetime DEFAULT CURRENT_TIMESTAMP, update_time datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_emp_no (emp_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT员工表;有几个字段是踩过坑总结出来的。工号emp_no必须唯一员工离职后再入职不能复用同工号否则历史工资和考勤记录会串号。身份证号id_card在数据库里要存但页面展示必须脱敏只显示后四位这是答辩时能主动讲出来的亮点。deleted逻辑删除字段必须有员工离职不能物理删记录否则工资历史就对不上了。3.2 考勤表和工资表的唯一约束数据不乱的关键考勤表的坑在于一天一条记录的约束。CREATE TABLE attendance ( id bigint NOT NULL AUTO_INCREMENT, emp_id bigint NOT NULL COMMENT 员工id, work_date date NOT NULL COMMENT 考勤日期, check_in_time datetime DEFAULT NULL COMMENT 上班打卡时间, check_out_time datetime DEFAULT NULL COMMENT 下班打卡时间, status tinyint DEFAULT 0 COMMENT 0正常 1迟到 2早退 3缺勤, PRIMARY KEY (id), UNIQUE KEY uk_emp_date (emp_id, work_date) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT考勤表;UNIQUE KEY uk_emp_date (emp_id, work_date)这行是灵魂。没有它同一员工一天可能插入多条考勤薪资统计时天数就会翻倍。至于打卡逻辑不用设计成复杂的上班点一次、下班点一次反而应该允许打了卡再打一次就是更新下班时间——这更贴近企业考勤机的行为。工资表和考勤表同构唯一约束是(emp_id, salary_month)保证一个员工一个月只有一条工资记录。字段建议分三组应发项基本工资、岗位工资、加班工资、扣款项社保扣款、缺勤扣款、迟到扣款、实发工资。把中间过程全存下来将来无论怎么对账都有据可循。3.3 一条员工记录的一生如何被多个表串起来理解表之间的关系最有效的方式是走一遍数据流。新员工入职时employee表插入一条数据同时user表创建一条登录账号这两个动作要在同一个事务里完成。之后每天上下班attendance表不断新增或更新记录。月底进入薪资核算系统读取该员工当月所有考勤记录统计出迟到次数、缺勤天数再结合salary_config里的工资基数算出应发工资、扣款和实发工资写入salary表。整个过程涉及员工、考勤、配置、工资四张表任何一张表的字段设计有缺陷这条链路都走不顺。数据流理解了文档里的ER图画起来也顺手dept与employee是一对多employee与user是一对一employee与attendance是一对多employee与salary是一对多。很多人的ER图画得混乱本质是没有先理清这张数据流图。4. 从登录到薪资核心模块的编码顺序与关键实现4.1 开发顺序先跑通登录再做框架页再叠加CRUD很多新手拿到项目第一步就去写员工管理的增删改查结果写完发现登录还没做所有页面裸奔最后补权限时到处改代码。我推荐的编码顺序是这样的创建Spring Boot工程配置好application.yml和MyBatis-Plus。实现登录接口和登录拦截器。搭后台框架页左侧菜单、顶部用户信息、右侧内容区。完成部门管理因为员工表要绑定部门。完成员工管理分页查询、条件检索、新增、编辑、离职。完成考勤模块打卡接口和按月统计。完成薪资模块工资计算和工资条查看。补公告模块和个人信息页。这个顺序值得说道说道。登录是权限体系的地基但注意登录只需要校验用户名密码、写Session先不要纠结角色权限细节。第二步的框架页决定了后面所有功能的展示载体要先固定下来。部门先行是为了员工页面里的部门下拉框有数据来源。每一步都有可见成果心理压力也小很多。4.2 登录拦截器10行代码守住整个后台登录拦截器是Spring Boot里最好讲又最实用的代码片段答辩时被问概率很高。public class LoginInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { Object loginUser request.getSession().getAttribute(loginUser); if (loginUser null) { response.sendRedirect(/login); return false; } return true; } }注册到WebMvcConfigurer里Configuration public class WebConfig implements WebMvcConfigurer { Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(new LoginInterceptor()) .addPathPatterns(/**) .excludePathPatterns(/login, /css/**, /js/**, /images/**); } }这段代码的逻辑一句话就能说清除了登录页和静态资源所有请求都必须先过Session检查。后续想在拦截器里加角色权限判断也只要再取一次loginUser.getRoleCode()做分支就行。4.3 考勤打卡一次请求背后要判断三种情况打卡接口的实际逻辑比想象中有意思。员工点击打卡后端拿到当前员工的ID和当前时间要做如下判断当天第一次打卡attendance表插入一条记录把check_in_time设为当前时间。当天已有check_in_time更新check_out_time为当前时间。迟到判断如果check_in_time晚于公司规定的上班时间状态标记为迟到。写出来就是Service层里的一段判断逻辑public Result punch(Long empId) { LocalDate today LocalDate.now(); Attendance att attendanceMapper.selectOne( new LambdaQueryWrapperAttendance() .eq(Attendance::getEmpId, empId) .eq(Attendance::getWorkDate, today)); if (att null) { att new Attendance(); att.setEmpId(empId); att.setWorkDate(today); att.setCheckInTime(LocalDateTime.now()); att.setStatus(0); attendanceMapper.insert(att); } else if (att.getCheckOutTime() null) { att.setCheckOutTime(LocalDateTime.now()); attendanceMapper.updateById(att); } else { return Result.error(今日已完整打卡无需重复操作); } return Result.success(); }迟到不再是员工手动选的而是系统根据打卡时间和规则自动标记这是跟假考勤最本质的区别。演示时故意选一个迟到场景评委能直观看到规则生效。4.4 薪资计算用BigDecimal别用double薪资计算是这道题里业务含量最高的地方也是拉开档次的地方。简单规则如下应发工资 基本工资 岗位工资 加班工资 应扣款项 缺勤天数 × (基本工资 / 当月应出勤天数) 迟到次数 × 单次迟到扣款 实发工资 应发工资 - 应扣款项 - 社保扣款核心代码如下public BigDecimal calcSalary(Long empId, String month) { Employee emp employeeService.getById(empId); SalaryConfig config salaryConfigService.getByEmployeeId(empId); // 当月出勤天数这里由考勤统计得出 MonthAttendanceStat stat attendanceService.statMonth(empId, month); BigDecimal baseSalary config.getBaseSalary(); BigDecimal postSalary config.getPostSalary(); BigDecimal overtimePay stat.getOvertimePay(); BigDecimal total baseSalary.add(postSalary).add(overtimePay); // 缺勤扣款 日均工资 × 缺勤天数 BigDecimal dailyWage baseSalary.divide(new BigDecimal(21.75), 2, RoundingMode.HALF_UP); BigDecimal absenceDeduction dailyWage.multiply(new BigDecimal(stat.getAbsenceDays())); // 迟到扣款每次50 BigDecimal lateDeduction new BigDecimal(stat.getLateCount()) .multiply(new BigDecimal(50)); BigDecimal actual total.subtract(absenceDeduction).subtract(lateDeduction) .subtract(config.getSocialSecurity()); return actual.setScale(2, RoundingMode.HALF_UP); }这里有两个细节务必注意。第一金额计算必须用BigDecimal用double做浮点运算会出现0.10.20.30000000000000004这种尴尬问题答辩现场很容易被问倒。第二月计薪天数用21.75这个标准值而不是自行拍脑袋回答为什么除以21.75时就可以搬出《关于职工全年月平均工作时间和工资折算问题的通知》一下子体现出专业度。4.5 Excel花名册导出把员工数据一键导出的常见姿势人事系统里Excel导出是看着不起眼、但评委特别容易点一下试试的功能建议加上。用EasyExcel最省事比POI少写一堆IO代码。public void exportEmployeeList(HttpServletResponse response, String deptId) { ListEmployee list employeeService.listByDept(deptId); ListEmployeeExcelVO data list.stream().map(e - { EmployeeExcelVO vo new EmployeeExcelVO(); BeanUtils.copyProperties(e, vo); vo.setIdCard(maskIdCard(e.getIdCard())); return vo; }).collect(Collectors.toList()); EasyExcel.write(response.getOutputStream(), EmployeeExcelVO.class) .sheet(员工花名册) .doWrite(data); }导出的数据里身份证号做一次脱敏再落盘这个习惯会加分。配合前面的ExcelProperty(工号)注解导出表头直接就齐了。5. 文档和PPT不是凑字数答辩评委真正想看的几张图和几组数据5.1 设计文档结构比字数重要标题里既然写了含文档PPT源码说明文档和PPT是用户真实交付物。设计文档的目录我建议按下面的结构写跟项目代码一一对应第1章 绪论研究背景、意义、国内外现状第2章 需求分析角色分析、功能需求、用例图第3章 系统设计总体架构、功能模块图、技术选型理由第4章 数据库设计ER图、核心表结构说明第5章 系统实现各模块截图、关键代码与说明第6章 系统测试测试环境、测试用例表、测试结果总结与展望每个章节的含金量是不同的。数据库设计这一章只要把ER图画清楚再把表的字段设计理由写两三段就成功了一大半。系统实现这一章不要贴大段大段代码重点是功能截图功能描述关键逻辑一句话截图要真实运行环境下的截图不要拿设计稿摆拍。测试章节最省事也最容易被忽视我建议列出15条左右的测试用例把输入、预期结果、实际结果、是否通过做成一张跨页表格比写十段测试描述都直观。5.2 答辩PPT十五分钟讲完的页面数量分配答辩PPT不是把文档复制一遍而是要服务十分钟到十五分钟的汇报节奏。页面数量控制在14到16页最合适。页码内容要点1封面题目、姓名、学号、指导老师2目录清晰列出汇报结构3研究背景与意义两到三句话带过4需求分析角色介绍 核心功能列表5用例图一张清晰的用例图6系统架构分层架构图表现层/业务层/持久层/数据库7数据库设计ER图缩小版8核心表结构员工表、考勤表、工资表9-13功能实现每个核心模块一页截图 三点说明14系统测试测试用例统计表15总结收获与不足功能实现那几页是全场重点每一页的结构固定为运行截图 这个模块解决什么问题 一句核心设计亮点。比如考勤模块的亮点就是数据库唯一约束保证一人一天一条记录状态自动判定迟到早退薪资模块的亮点就是用BigDecimal做金额计算扣款规则可配置。这一页的价值比代码截图高得多因为评委听的是你的设计思路不是在读你的源码。5.3 源码交付时的三个文件README、SQL和演示脚本源码交付不要只丢一个压缩包。我交付项目时一定包含三个东西一是README.md写清楚JDK版本、MySQL版本、数据库初始化步骤、启动指令、初始账号密码。很多同学源码能跑起来全靠自己电脑里乱七八糟的配置换台机器就起不来README是让别人成功跑起来的操作手册。二是database/hrms.sql完整的建库建表脚本最好带上几条演示数据。这里要注意演示数据不要只填两三条部门至少三个、员工至少六个、考勤至少一个月的否则薪资计算没有数据支撑。三是演示脚本也就是一页纸的演示流程清单从登录进入系统先看数据概览然后查员工、打卡、算工资、导出Excel、查看工资条每一步点哪里、预期看到什么。答辩前照着走两遍比背十页讲稿都有用。6. 拷贝源码容易跑通环境才是第一道坎JDK、数据库与部署全过程6.1 本地环境四个坑JDK、MySQL、IDEA、Maven从网上下载源码后卡在环境上的人最多。第一个坑是JDK版本。Spring Boot 2.7配JDK 8或11都没问题但很多人电脑里既有8又有17环境变量配乱了。我的建议是坚决统一成JDK 8验证方法就一条命令java -version看到1.8字样再继续否则先改JAVA_HOME和PATH。第二个坑是MySQL时区。用MySQL 8.0连接时如果URL里少了时区参数启动就会报The server time zone value йʱ is unrecognized。解决方案很简单连接串里加上jdbc:mysql://localhost:3306/hrms?serverTimezoneAsia/ShanghaicharacterEncodingutf8useSSLfalse第三个坑是Maven依赖下载慢。国内直接把Maven仓库地址换成阿里云镜像在settings.xml里加一行mirror配置否则等依赖下载能等半小时。第四个坑是数据库初始化。拿到项目的SQL脚本后先手工建一个hrms数据库再导入SQL。很多人直接在系统自带数据库里执行结果表创建到一半报错因为编码集或外键顺序不对。规范做法是mysql -uroot -p CREATE DATABASE hrms DEFAULT CHARACTER SET utf8mb4; exit mysql -uroot -p hrms hrms.sql6.2 常见启动失败端口占用、数据库连不上、jdk版本不符启动失败是咨询量最大的问题我把频率最高的三种写出来APPLICATION FAILED TO START Web server failed to start. Port 8080 was already in use.这是端口被占。要么改application.yml里的server.port要么找出占用进程杀掉。Windows下用netstat -ano | findstr 8080看PID然后taskkill /F /PID 进程号。java.sql.SQLNonTransientConnectionException: Could not connect to MySQL这是数据库没连上。按顺序排查MySQL服务是否启动、账号密码是否正确、连接串里的库名是否存在。很多人栽在最蠢的地方——密码是错的。Error creating bean with name sqlSessionFactory这种通常是JDK版本或依赖冲突。看看Maven里是否引入了多个不同版本的MyBatis依赖把全部依赖删掉后重新mvn clean install一次。6.3 从本地跑通到Linux服务器部署jar包运行的标准姿势本地跑通之后想进一步展示工程能力可以把系统部署到一台Linux服务器上这也是很多招聘JD里的加分项。流程不复杂第一步在项目根目录执行打包命令mvn clean package -DskipTests第二步把target目录下生成的hrms.jar上传到服务器。第三步服务器上确认JDK和MySQL已经就绪然后后台启动nohup java -jar hrms.jar app.log 21 不要直接用java -jar hrms.jar在前台跑否则SSH窗口一关程序就没了。nohup加让进程在后台持续运行日志重定向到app.log排查问题就看这个文件tail -f app.log第四步浏览器访问http://服务器IP:8080。如果打不开一般不是程序问题而是防火墙或云安全组没放行8080端口。这一套流程走完源码跑通就成了项目部署上线演示说服力完全不一样。6.4 演示环境的小心机数据量、账号、截图提前备好最后说一个只有实战过才懂的经验答辩演示效果很大程度上取决于测试数据是否用心。我见过太多系统里只有一条张三测试数据打卡记录只有三天工资表完全空白。这样的演示功能做得再好也没说服力。我建议数据准备成这样的规模部门树总公司下挂行政部、技术部、市场部至少三层部门结构。员工数据每个部门6-8人工号连续有规律如EMP0001这种格式。考勤数据模拟最近一个完整月大部分正常出勤故意安排3-4天迟到、1-2天缺勤。工资数据连续算两个月让评委能看到上月和本月的对比。登录账号准备admin、manager1、emp001三个账号对应三种角色现场登录两个不同角色页面差异一目了然。演示时从管理员的登录看仪表盘到查员工、导出Excel再切到考勤汇总最后点开工资条一气呵成。数据有细节、流程有闭环这套演示下来基本没人会质疑系统是只做了页面没做业务的假把式。我个人在帮人审过无数个类似项目之后最大的体会是系统代码的复杂度永远是可控的真正拉开差距的是两个地方——数据库设计是否严谨、答辩表达是否有逻辑。源码跑通是底线但一定要对自己设计的每一张表、每一条业务规则都能说出为什么。做这个人事系统时我会把每张表的设计理由、每个功能背后的业务含义写在一张纸上梳理完再动手写代码。这个习惯比任何框架技巧都管用。最后分享一个小技巧答辩前把完整演示流程录一遍视频自己回放看看哪里有停顿、哪里被问住能流畅跑完整个流程这个项目基本就稳了。