企业官网建设流程全解析

每年到了毕业设计选题季，后台收到最多的问题几乎都是同一个：有没有一个项目，技术栈主流、业务不算复杂、做起来工作量适中、答辩时还拿得出手？如果你恰好也在找这个答案，那基于 SpringBoot、Vue、MySQL 的工资信息管理系统，是我这两年看下来最稳的一类选择。它覆盖员工信息管理、工资项目配置、工资核算、工资条查询、统计报表等完整业务闭环，既有明确的应用场景，又不至于像电商系统那样无限发散，非常适合本科阶段用来检验前后端开发能力。

这篇博文我会按自己做毕设指导时积累的经验，从选题价值、数据库表结构设计、后端权限与核算逻辑、前端页面组织、部署踩坑、论文与答辩准备几个维度，把这一整套系统的思路完整拆开讲。不管你是打算拿这套源码做二次改造，还是想用这个题目从零自己写一遍，这篇内容都能帮你避开不少弯路。

1. 为什么说工资信息管理系统是毕业设计的黄金选题

1.1 业务场景：一个工资系统的完整闭环

很多人选毕设题目的时候有个误区，觉得越"高级"越好，比如搞个秒杀系统、推荐系统、微服务中台。但实际上本科毕设最看重的是两件事：一是你能把一个业务场景讲清楚，二是你能用合适的技术把它落地。工资管理系统在这两点上天然占优势。

工资管理这件事，业务链路非常明确：人事先把员工基础信息维护好，然后每个工资周期收集考勤、绩效、补贴等数据，系统按配置好的工资项目自动核算，生成工资单，财务确认后进行发放，员工端可以随时查看自己的工资条，管理层还能看到月度工资总额、部门工资占比等统计报表。这个流程是一个完整的闭环，既有数据的写入（员工信息、工资项目）、又有计算逻辑（工资核算、个税模拟）、还有查询统计和权限控制，该有的都有了，但复杂度又在可控范围内。

相比之下，商城系统虽然也常见，但涉及商品、订单、购物车、支付、库存、优惠券，光是状态流转就能让不少同学理不清楚；而图书管理系统又太过单薄，往往只是简单的增删改查，评委一眼就能看出工作量不足。工资管理系统处在一个很均衡的位置——CRUD有，但不是纯CRUD；业务逻辑有，但不至于复杂到失控。

1.2 功能边界：系统模块划分与角色权限

功能设计上，这套系统通常划分成六大块：员工管理、部门管理、工资项目管理、工资核算与发放、工资条查询、统计报表，再加上系统管理。每个模块背后都有清晰的数据流和页面流。

角色权限方面，最常见的方案是分成三种：管理员（拥有全部权限）、财务/人事专员（可以维护员工信息、进行工资核算与发放）、普通员工（只能查看自己的工资条和个人信息）。权限设计本身就是毕业设计里一个很有分量的加分点，因为它涉及到的是"功能权限控制"这个通用话题，而不只是业务本身。

这里有一个很多初学者容易搞混的点：权限控制不等于登录拦截。登录只是验证你是谁，权限控制是决定你能看到什么、能操作什么。工资管理系统里这点特别敏感——普通员工一定不能看到其他同事的工资，财务角色也不能随便改工资项目的计算公式。把这几类角色的数据权限和操作权限理清楚，论文的需求分析和系统设计部分就已经有内容可写了。

1.3 这套系统适合什么基础的人来做

如果你是Java后端方向，但前端只写过一点点HTML/CSS/JavaScript，这套系统仍然适合你。后端部分用SpringBoot做接口、MyBatis-Plus做数据库操作、Spring Security或拦截器做权限控制，都是Java生态里的标准操作；前端部分用Vue配上Element UI组件库，不需要你有多么厉害的前端审美，照着组件文档搭页面就行了。

工作量上也很好预估：数据库表大概8到12张，后端接口40到60个，前端页面10到15个。一个人按每天4到6小时的有效开发时间算，认真做的话大概三到四周能完成全部功能，剩下时间写论文、调部署、准备答辩，节奏非常从容。

2. 技术选型背后的逻辑：为什么是SpringBoot+Vue+MySQL

2.1 SpringBoot给后端带来的开发效率

如果放在七八年前，做JavaWeb项目的主流还是SSH（Struts2+Spring+Hibernate）或者SSM（Spring+SpringMVC+MyBatis），光是配置XML文件就能耗掉一两天。现在用SpringBoot，核心优势就是"约定大于配置"：内嵌Tomcat让你不用单独装容器，自动配置帮你把数据源、MyBatis、JSON序列化这些基础工作都处理好，你只需要专注于写业务代码。

对毕设而言，SpringBoot还有一个很现实的好处：网上的资料多到爆炸。你遇到的绝大多数问题，比如数据库连不上、端口被占、依赖版本冲突，随便一搜就有解决方案。选型的时候"生态成熟度"本身就是一项重要指标，不要为了显得技术新去选一个刚出了没两年的框架，那只会让你在DEBUG上耗尽宝贵的毕设时间。

有同学可能会问，那用SpringCloud微服务是不是更高级？我的建议是克制一点。毕设核心是讲清楚业务和技术落地，微服务引入的服务注册、配置中心、分布式事务等问题，每一个都能再写一篇论文，而且本地部署调试的成本也高得多。单体的SpringBoot应用，配合合理的分层和接口设计，完全足够体现你的工程能力。

2.2 Vue在前端带来的维护体验

Vue这套组合里最舒服的一点是数据驱动视图。你不需要像用jQuery那样频繁操作DOM，只需要维护好data里的数据，页面会自动更新。工资核算页面那个场景特别典型：选择月份、点击核算、返回一张工资明细列表，在Vue里就是改一个数组的事，数据一变表格刷新，体验非常顺滑。

再加上Element UI这套组件库，表格、弹窗、表单、日期选择器、分页组件都是现成的。页面布局直接用Container布局组件做侧边栏加顶栏的后台管理框架，一个后台管理系统的"壳"十分钟就能搭好。可以说，Vue极大降低了"把后端功能变成可视化界面"的门槛。

另外前后端分离的开发模式本身也是当前企业开发的主流。前端用Vue开发服务器上跑在8080，后端SpringBoot跑在8081，通过接口联调，前后端只需要约定好JSON格式，各自并行开发互不阻塞。论文里就写一句"系统采用前后端分离架构"，评委一看就知道你跟过项目或者至少做过功课。

2.3 MySQL在数据存储上的取舍

MySQL在这套系统里几乎是唯一合理的选择。一方面它是开源免费的，本地装一个不用考虑授权问题；另一方面它跟SpringBoot的整合非常顺畅，无论是用JDBC、MyBatis还是MyBatis-Plus，驱动和方言都是一把梭。

可能有人会问，用Oracle或者SQL Server是不是显得更"企业级"？且不说这两个数据库安装包体积和配置复杂度，平时练习资料也没MySQL多。真到了写论文阶段，MySQL的ER图绘制、Navicat可视化操作、导出SQL脚本这些流程，都有大量现成工具和教程可以配合，省下来的时间用来打磨系统功能和论文细节，性价比高得多。

选MySQL还要注意版本问题。现在新装的一般都是MySQL 8.0，默认认证插件是caching_sha2_password，和旧版驱动连接时会出现认证失败的报错。解决办法有两个：要么在连接串里加上allowPublicKeyRetrieval=true，要么在创建用户时指定mysql_native_password。这个坑后面部署部分会细讲。

3. 数据库设计：工资管理系统的表结构与字段规划

3.1 核心表清单与关系梳理

数据库设计是整个系统的地基。这张表设计得是否合理，直接决定后端代码好不好写、论文系统设计部分有没有内容。我按实际项目里的常用方案，把核心表梳理如下：

这些表的关系也很直观：department和employee是一对多，employee和salary是一对多，salary和salary_detail是一对多。sys_user和employee可以设计成一对一——每个员工账号对应一个员工档案，也可以简单一点，直接在employee表里加用户名密码字段，按角色区分。

我个人的建议是拆成sys_user和employee两张表，这样论文里可以多画一张E-R图，而且从工程上讲，登录账号和业务档案分离也更合理。员工离职之后，账号可以禁用，但历史工资数据要保留，这是工资系统里的一个基本要求。

3.2 工资表字段设计的细节

工资主表salary是整个系统的核心，它的字段设计直接关系到核算逻辑好不好写。建议至少包含这些字段：id、employee_id、salary_month（工资所属月份）、base_salary（基本工资）、post_salary（岗位工资）、performance_salary（绩效工资）、overtime_salary（加班费）、allowance（补贴）、social_security（社保）、housing_fund（公积金）、tax（个税）、deduction（考勤扣款）、gross_salary（应发合计）、net_salary（实发合计）、status（草稿/已发放）、create_time。

为什么要把这些项目拆成字段而不是存一个总额？因为工资条的展示需要明细。员工要能看到我这个月基本工资多少、绩效多少、社保扣了多少，你只给个总数，这个功能就没法实现。但同时也别拆得太细——比如把"餐补""交通补贴""住房补贴"全单独建成字段，那样又太死板了，后续加一个项目就得改表结构。

这里有个容易踩坑的点：工资明细里加了一条"津贴项"，但工资主表里没有对应的汇总字段。最常见的设计矛盾就在这。我的建议是：工资主表存的是固定的几个大类字段，工资明细表存的是工资项目的具体计算结果。如果将来需要扩展工资项目，只需要在salary_item表里加一行配置，不需要改主表结构，这就是"工资项目可配置"的思想。

3.3 金额字段的类型选择和两个常见设计错误

金额字段一定一定不要用double或者float。这两个类型是浮点数，存0.1在内存里可能是0.1000000000000000055511151231257827，算工资的时候差那么几分钱，虽然单看无所谓，但累加起来就会出现"实发工资对不上"的尴尬。所有涉及金额的字段都使用decimal，比如decimal(10,2)，即整数部分8位小数部分2位，足以容纳常见金额范围。

另外一个常见错误是把工资数据设计成"宽表"，也就是字段名是月份，例如january_salary、february_salary这样的列，表面上看查询某个员工的全年工资只要一行记录，但它带来的麻烦是：每个月都要改表结构或加字段，统计和汇总也非常痛苦。正确的做法是纵向存储：每一行代表某个员工某个工资周期的一条工资记录，通过salary_month字段来区分。这才是关系型数据库应该有的样子。

还有一个小细节容易被忽略：员工离职之后，部门可能调整，岗位也可能变更。工资系统里存工资单的时候，应该把当时的基本工资、岗位等快照冗余在工资表里，而不是只存一个employee_id然后去关联员工表。因为你不能保证员工表的数据永远不变，工资历史是"过去的事实"，不能被现在修改的数据影响。这个思路在论文里写出来非常加分，它有专业系统的味道。

4. 后端实现：SpringBoot的权限控制与工资核算逻辑

4.1 登录认证设计：JWT还是Session

后端开发里第一个要敲定的问题是登录认证方案。最传统的做法是Session，登录成功往session里塞个用户信息，后面的请求带着cookie就能识别；现在更流行的是JWT，登录成功后生成一个token返回前端，前端每次请求在请求头里带上Authorization字段。

毕业设计场景下，两种方案都能用，但我更推荐JWT，理由有三个：第一，前后端分离架构下，JWT天然适合无状态接口，前端不依赖cookie跨域问题少一堆；第二，论文里可以写"基于令牌的认证机制"，有概念深度；第三，实际企业项目中JWT非常普遍，写进简历里不虚。

实现上，用Java的jjwt库，核心代码也就几十行。登录接口校验用户名密码后生成token，然后写一个拦截器，校验请求头里的token是否有效。白名单就放行登录接口和一些静态资源，其他接口一律要走拦截器。这里有个细节要注意：token里不要放密码这种敏感信息，放个用户id和角色就够了，因为这些信息会被解析出来用在前端权限控制上。

4.2 工资核算的核心逻辑与幂等考虑

工资核算是后端代码里最体现业务能力的地方。核算规则通常是这样：

应发工资 = 基本工资 + 岗位工资 + 绩效工资 + 加班费 + 补贴 实发工资 = 应发工资 - 社保 - 公积金 - 个税 - 考勤扣款

社保和公积金的计算可以做一个简化模拟：社保按应发工资的10.5%计算，公积金按12%计算，这些比例可以在配置项里维护，不一定跟真实政策完全一致，但逻辑必须能自圆其说。个税计算用阶梯税率，比如月收入5000以内免税，超过部分按3%、10%、20%这样累进，哪怕只是模拟，也要让评委看出你理解了税率设计的原理。

代码层面，核算服务可以接收一个月份参数，查到这个月所有需要核算的员工，循环遍历，根据员工的工资项目和考勤数据逐项计算，生成salary和salary_detail记录。这里必须考虑一个场景：用户手快点了两次核算按钮，或者网络超时重试，数据库里就生成了两遍数据。解决思路是加唯一约束，在salary表上给employee_id和salary_month建联合唯一索引，第二次插入直接报错，程序捕获异常返回"当月工资已核算"。

一个被很多学生忽略但阅卷老师很看重的点是事务控制。工资核算涉及主表、明细表多次写入，任何一步失败都会导致数据不一致，一定要在核算方法上加上@Transactional注解。论文里写"基于Spring的事务管理机制确保数据一致性"，这一句话就比你多写一百行CRUD代码有分量。

4.3 查询接口与Excel导出的实现要点

列表查询要支持分页和条件筛选，直接用MyBatis-Plus的Page对象，或者PageHelper插件，都很成熟。常见查询条件包括：按员工姓名模糊查询、按月份查询、按部门查询。这里需要注意SQL注入问题，使用MyBatis-Plus的LambdaQueryWrapper，字段名是类型安全的，不会出现字符串拼接注入的情况。

工资条导出Excel功能建议用EasyExcel。它的API很友好，一个注解就能把实体类字段映射成Excel列名。导出的时候注意两点：一是表头样式和列宽要设置好，不然导出来挤成一团很难看；二是导出接口同样要做权限控制，普通员工不能导出全公司工资，只能导出自己那一条，不然就是严重的数据泄露事故。

关于员工查询自己工资的接口，还有一个数据权限的问题。如果只做了登录拦截不区分角色，那员工随便调一个接口就能遍历所有人的工资。解决办法是在查询参数的赋值上强制用当前登录用户的id，而不是让前端传userId。后端永远不要信任前端传的参数，这个习惯从现在开始就要养成。

5. 前端实现：Vue页面如何组织和对接后端

5.1 项目初始化、路由与页面骨架

前端建议用Vue2搭配Element UI，或者Vue3搭配Element Plus，看你自己熟悉哪个。如果是从零开始，我更推荐Vue2的成熟组合，网上资料多，遇到问题好搜。创建项目用vue-cli，或者现在新一点的Vite都可以。装好vue-router、axios、element-ui这几个依赖之后，先把页面框架搭起来。

后台管理系统最常见的布局就是左侧菜单栏加右侧内容区。Element UI提供了现成的Container布局，菜单根据路由配置动态渲染。路由设计上，/login是登录页，首页是Dashboard，员工管理、部门管理、工资项目、工资核算、工资条查询、统计报表各占一个子路由，未登录用户访问任何页面都重定向到登录页。

路由守卫的写法很固定：在router.beforeEach里检查本地有没有token，没有就跳登录页，有就去下一站。这里有个小坑：token过期怎么办？接口返回401的时候，前端要捕获这个状态，清掉本地token，跳回登录页。很多学生只做了"有token就能进"，忽略了"token无效要踢出去"这一步，联调的时候经常出现莫名白屏。

5.2 核心页面的交互与实现思路

员工管理页面是标准的CRUD页面：搜索栏加表格加弹窗表单加删除确认。搜索栏里放员工姓名和部门下拉框，表格展示员工编号、姓名、部门、岗位、基本工资、状态，操作列里放编辑和删除按钮。弹窗表单里按字段填基础信息，前端用rules做必填校验，提交时POST到后端。

工资核算页是系统里交互稍微复杂一点的页面。页面顶部放一个月份选择器，选择之后点"开始核算"按钮。前端用axios发请求，按钮要加loading状态防止重复点击。后端返回核算成功后，刷新下方的核算结果表格，展示本月工资总额、发放人数等汇总信息。这个页面的体验做得好不好，最能体现开发者的细节意识。

统计报表页面用ECharts画图表。可以做的图形包括：月度工资总额折线图、部门工资占比饼图、员工工资排名条形图。ECharts的使用不复杂，关键是数据从哪里来。后端可以提供一个聚合统计接口，直接返回按部门分组或按月份分组的金额数据，前端只需要把数据塞进chart的option里。如果你想让论文里的截图更丰富，这个页面多放两张图非常划算。

5.3 前后端联调最容易踩的三个坑

第一个坑是跨域问题。前端在8080端口跑，后端在8081端口跑，前端直接发请求会被浏览器拦截。解决办法有两种：最简单的是在后端写一个CorsConfig配置类放行所有跨域请求；更推荐的做法是前端在vue.config.js里配devServer的proxy代理，把/api开头的请求转发到后端8081端口。生产环境用Nginx反向代理也是同样的道理。用代理可以少许多跨域问题，也更接近真实项目部署方式。

第二个坑是时间格式不一致。后端返回LocalDateTime类型，序列化成JSON之后可能是"2024-05-20T15:30:00"，前端表格里显示得很丑。解决办法是在后端的application.yml里统一配置Jackson的时间格式：yyyy-MM-dd HH:mm:ss。这个配置写一次，所有接口都生效，属于那种"不知道就要挨个接口改"的经典问题。

第三个坑是字段命名。Java后端习惯驼峰命名（salaryMonth），MySQL字段习惯下划线命名（salary_month），前端Vue里拿数据时也要对应。用MyBatis-Plus的驼峰映射开关可以自动转换，但如果你手写了XML的resultMap，就要特别注意映射关系，写错一个字段，页面上那一列就是空的。排查这种问题最快的办法，是先在浏览器Network里看接口返回的JSON里有没有这个字段，再去看前端是否取对了字段名。

6. 本地部署与服务器部署：从环境准备到上线

6.1 本地环境准备清单

毕设交付的时候，评审老师很少会要求你把项目部署到公网服务器上，但本地能跑起来是底线。环境准备建议按这个清单来核对：

• JDK：1.8或者11都可以，记得配好JAVA_HOME环境变量
• Maven：3.6以上，配置好阿里云镜像仓库，不然下载依赖会很痛苦
• Node.js：14以上，npm安装依赖时如果卡住，换淘宝镜像源
• MySQL：8.0或5.7，安装时记住密码，Navicat连上能建库
• IDE：IDEA或Eclipse，导项目的时候注意选择Maven项目导入，等依赖全部下载完再启动

数据库初始化是最先要做的事。用Navicat新建一个数据库，比如命名为salary_system，字符集选utf8mb4，然后右键运行SQL文件，把项目提供的初始化脚本导进去。这样数据库里就有表结构和初始数据了。检查一下有没有数据，用SELECT * FROM employee查一下，出来几条员工数据就说明导入成功。

6.2 后端启动与前端启动细节

后端启动前，检查application.yml里的数据源配置。数据库账号、密码、URL里的数据库名一定要和本地一致，尤其是URL里的时区和SSL参数：

spring: datasource: url: jdbc:mysql://localhost:3306/salary_system?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai&allowPublicKeyRetrieval=true username: root password: yourpassword

如果漏了useSSL=false，MySQL 8.0会报SSL连接错误；漏了serverTimezone，又会报时区错误。这两个是新手最常见的前两个报错。后端启动成功后，控制台会输出SpringBoot的启动日志，最后一行是Tomcat started on port 8081，看到这个就说明后端接口可以访问了。

前端启动简单一些，进入vue项目目录，先执行npm install安装依赖，再执行npm run dev启动开发服务器。浏览器打开localhost:8080，看到登录页就说明前端OK。如果npm install过程中报错，先检查Node版本是不是过新或过旧，再检查是否设置了淘宝镜像源。很多Vue项目跑不起来，都是依赖没装干净导致的。

6.3 服务器部署：把项目放到公网让手机也能访问

如果你想让毕设再上一个档次，可以买一台便宜的云服务器（学生认证一般有优惠），把系统部署上去，论文里写一句"系统已部署至云服务器，可通过域名访问"，评委印象分直接拉高。部署方式有两条路，按你的Linux熟练程度选。

方案A是用宝塔面板。装好宝塔后，软件商店装Nginx和MySQL，然后手动上传前端打包文件和后端jar包。前端运行npm run build生成dist目录，把这个目录上传到服务器；后端用mvn package打成jar包，用java -jar启动。Nginx配置一个反向代理，把/api开头的请求转发到后端端口，再把根路径指到dist目录。这样手机浏览器输入服务器IP就能访问系统。

方案B是纯命令行部署，适合对Linux有点基础的人。核心命令就这几条：yum install nginx、systemctl start nginx、scp上传文件、java -jar xxx.jar --spring.profiles.active=prod。如果你完全没接触过Linux，先用方案A，图形界面操作不容易误伤系统。

6.4 部署中的高频报错和排查思路

部署阶段我最常被问到的问题，翻来覆去就是那么几个。第一个是数据库连接失败，报Communications link failure，十有八九是数据库端口没放开或者没设置远程访问权限。MySQL默认只允许localhost连接，云服务器上要创建一个远程用户，或者把root的host改成%。

第二个是端口被占用，报Port 8081 was already in use。解决方案很简单，用netstat -anp | grep 8081看谁占用的，要么kill进程，要么改application.yml里的端口。

第三个是前端页面能打开，但所有接口都404。这个基本都是Nginx反向代理配错了。检查conf文件里location /api那段是否写对，以及proxy_pass最后有没有带末尾斜杠。一个斜杠之差，效果天差地别。

还有同学会遇到npm run build之后，打开页面是一片空白。这个通常是publicPath配成绝对路径了，需要在vue.config.js里把publicPath设为'./'，让打包后的资源使用相对路径，才能适应不同部署目录。

7. 论文写作与答辩准备：把项目变成一份合格的毕业设计

7.1 论文结构怎么搭最合理

毕业设计论文的结构大同小异，一般按七章来写：绪论、相关技术介绍、需求分析、系统设计、系统实现、系统测试、总结。这里的重点不是章节名称，而是每一章该放什么内容。

需求分析章的核心是用例图。画出管理员、财务、员工三个角色的用例图，每个模块的功能点都在用例图上体现出来。这一章不需要写太多文字，真正有价值的是图上标注的功能边界。系统设计章放架构图、功能模块图、E-R图和主要表结构说明。这里要特别注意，论文里的图一定要自己画，哪怕画得丑一点，也不能直接截几个别人博客里的图往上贴，查重和答辩时都会被一眼识破。

系统实现章倒是可以实测截图，登录页截图、员工管理页面截图、工资核算页面截图，配上对应的代码片段和说明。代码不要贴大段大段的，挑核心的部分，比如工资核算方法、JWT拦截器、导出接口，每种贴个十几行就够了，重点是讲清楚思路。

7.2 论文里最容易翻车的几个点

第一个是图表和代码不一致。比如论文里写了"系统支持按部门统计工资占比"，但截图里的图表根本没体现部门维度，这是硬伤。写论文前先把系统功能跟设计保证一致，论文里写的每一个功能点都要能在系统里实际操作出来。

第二个是测试数据没有说服力。系统测试这一章，很多人都是随便填几个假的测试结论，比如"功能测试通过""性能良好"，没有任何数据支撑。比较好的做法是：先设计测试用例表，每条用例包含测试步骤、预期结果、实际结果，然后再给出测试结论。有张表在上面，这一章至少能撑两页纸，而且看起来专业。

第三个是参考文献胡乱凑数。有些同学参考文献列了一堆根本没看过的书，答辩时评委问一句"这篇文献的核心理念是什么"，直接哑火。正确的做法是列10到15篇自己确实参考过的、国内核心期刊或技术文档类的文献就行，宁可少一点，也不要编造。

7.3 答辩高频问题与回答思路

答辩常见的几个问题，基本可以提前准备好腹稿。第一个必问题：为什么选工资管理系统这个题目？回答思路是业务需求普遍、功能边界清晰、技术栈能覆盖主流开发模式，同时结合实习或课程设计经历，显得选题有依据。

第二个问题：工资核算的具体流程是什么？这时候你就把核算规则按步骤讲清楚，基本工资加绩效加补贴减去社保公积金个税，并说明事务控制和唯一约束怎么保证数据不出错。能讲清楚这个，说明项目是真实做过的。

第三个问题：你的权限控制是怎么实现的？你回答基于JWT认证加后端角色校验，普通员工接口查询强制绑定登录用户ID，财务和管理员拥有不同操作权限。这个问题回答好了，基本能看出你已经理解权限控制的本质了。

第四个问题通常偏开放性：如果用户量变大，系统怎么优化？不需要你真的去优化，只要说出思路就行：数据库加索引、Redis做缓存、Nginx负载均衡、前后端分离本身就便于横向扩展。有条理地列出几个点就行，不要急着说"我不会"。

答辩的核心不是你的项目有多牛，而是你对项目的理解有多深。写论文的过程本身就是一次深度梳理，把自己做过的每一个功能都过一遍"为什么这么做""不这么做会怎样"，能回答清楚这两个问题的，基本不会在答辩台上卡住。

最后再说一点个人体会：毕业设计这件事，选好题目就是成功的一半，而工资管理系统恰好是一个"上限很高、下限能保底"的题目。手里有这套源码和文档，也不要急着直接照抄交付，一定自己把核心模块的代码重新读一遍、跑一遍、改一改，哪怕只改一个字段、加一个筛选条件，这套系统才真正变成了"你的成果"。答辩的时候，你能说出每一行关键代码的来龙去脉，比任何华丽的包装都管用。