企业官网建设流程全解析

1. 项目概述

1.1 从标题里读出来的核心需求

"基于JavaWeb和MySQL的SpringBoot企业员工绩效工资管理系统"，这个标题信息量其实不大，但它几乎覆盖了绝大多数中小型企业在薪酬管理上的共同痛点。我最早接触这类项目，是在给一家做制造加工的企业做信息化改造的时候。对方HR部门还在用Excel算绩效工资，每个月月底那几天，三四个人的小团队加班到深夜，就为了把考勤、绩效系数、计件数据、补贴扣款这些零零散散的东西汇总到一张表里。算完之后还要担心公式有没有漏、数据有没有错、某个员工的工龄工资是不是又填反了。后来把这个系统搭起来之后，整个核算流程压缩到半天以内，而且每笔金额都能追溯到原始数据源。

这个项目之所以选SpringBoot加MySQL的组合，不是因为它新潮，而是因为它稳。SpringBoot把Spring那套复杂的配置收敛成了极少量的自动化配置，对于企业内网部署的JavaWeb应用来说，开发和维护成本都控制得非常低。配合Freemarker做服务端渲染，不需要单独拆前后端，部署时只需一个可执行的JAR包，扔到服务器上就能跑。MySQL则承载所有业务数据，从部门、岗位、员工到绩效指标、工资明细，一张库表对应一块业务模块，结构清晰、查询高效。

如果你是刚学完JavaWeb或者SpringBoot、想找一个练手项目作为毕设或面试作品，这套系统非常合适。它覆盖了典型的CRUD操作、文件导入导出、登录权限控制、复杂业务逻辑计算、多表关联查询，技术广度够，但深度要求又不像微服务那样劝退新人。就算你已经有几年经验，这类项目在重构和优化上也很有价值，比如把Freemarker换掉改成前后端分离、引入Redis缓存热点数据，都是很好的演进方向。

1.2 这套系统的业务边界

在开始动手之前，先明确系统要管什么、不做什么。我见过很多项目失败在需求无限膨胀上——今天想加个考勤打卡，明天想对接企业微信，后天又想搞个智能绩效分析，最后代码写了一堆，核心功能反而一塌糊涂。

这个项目的核心业务边界就五块：员工管理、部门岗位管理、绩效管理、工资核算、系统权限管理。再往里拆：

• 员工管理：新员工入职建档、员工信息批量导入、离职员工停用、员工信息修改。
• 部门岗位管理：维护企业组织架构，一个部门下挂多个岗位，每个岗位有对应的基本工资区间。
• 绩效管理：定义绩效指标和权重，为员工录入绩效评分，自动计算绩效工资。
• 工资核算：根据基础工资、绩效工资、津贴、加班费、社保扣款、个税等参数，生成月度工资表。
• 系统权限管理：登录认证、角色的菜单权限和数据权限控制，至少要有管理员和普通HR两种角色。

不做的部分也很明确：不接考勤机硬件，不做工资条自动推送，不做复杂的审批流。考勤数据可以做成Excel导入，工资条可以导出PDF让员工自己查，审批流在企业内部还没那么规范的时候硬做就是给自己挖坑。把边界立住，系统才能在一个周末的时间里真正落地。

2. 技术选型背后的逻辑

2.1 为什么是JavaWeb + SpringBoot组合

很多人会纠结一个问题：现在微服务这么流行，为什么还要用单体SpringBoot结构来写企业管理系统？答案很简单——这个系统压根用不着微服务。微服务解决的是团队协作、独立部署、弹性扩展的问题，而一个几十上百人规模的企业，单机部署一套Jar包完全够撑住日常访问量。把系统拆成N个微服务，反而要处理服务发现、配置中心、分布式事务之类的问题，成本远大于收益。

SpringBoot在这里扮演的角色，是让JavaWeb开发回归到"关注业务逻辑"本身。传统的Spring MVC项目需要手动配置web.xml、Spring容器、MyBatis的SqlSessionFactory，配错一个扫描路径就找半天。在SpringBoot里，通过starter依赖自动装配，大部分配置都变成了约定俗成，比如spring-boot-starter-web会直接把内嵌Tomcat、DispatcherServlet、Jackson序列化都准备好。你只需要写Controller、Service、Mapper三件套，把精力放在业务实现上。

再说回JavaWeb这一层。企业级管理系统往往面临各种奇怪的环境要求：某些老旧的服务器还在用JDK 8，数据库不能随便动，内网隔离无法访问外网。Java的跨平台能力和SpringBoot的兼容性在这种环境里优势明显。而且将来如果要把系统升级成分布式架构，SpringBoot本身也是SpringCloud的基础，到时候把服务拆开加个注册中心就行，不用推翻重来。

2.2 MySQL在工资数据管理中的地位

工资数据的最大特点是"月末集中计算、全年持续存档"。MySQL这类关系型数据库在工资场景下有几个天然优势：

• 事务能力强：每月算工资涉及多个表的读写，任何一步失败都要整体回滚，事务能保证数据一致。
• 关联查询方便：员工、部门、绩效、工资明细之间有明确外键和索引，SQL可以灵活组合多表查询，统计报表也能直接用GROUP BY搞定。
• 数据备份成熟：mysqldump、主从复制、binlog日志都有成熟方案，工资数据是敏感资料，备份和恢复能力必须可靠。

在MySQL里设计工资表有一个容易踩的坑：金额字段不要用decimal精度太小的问题。工资计算涉及浮点乘除，如果字段用float或double，会出现0.1+0.2不等于0.3的精度问题。我用过的方案是所有跟钱相关的列都定义为DECIMAL(10,2)，在Java侧对应BigDecimal，计算时也用BigDecimal而不是double。别嫌麻烦，这一步稳住了，后续对账才不会出幺蛾子。

另外字符集和排序规则我习惯统一为utf8mb4和utf8mb4_general_ci。考虑到有些员工姓名里会带生僻字，假若是gbk或普通utf8，插入时很可能报"Data too long"或者乱码。utf8mb4是最稳妥的选择。

2.3 Freemarker模板引擎为什么比JSP舒服

现在网上大量教程在推前后端分离，Vue加SpringBoot写成接口式开发。但对企业内部管理系统来说，Freemarker这种服务端模板引擎依然有不可替代的地方。Freemarker在SpringBoot里集成非常顺，它的核心思想是思路与表现分离：模板文件里写HTML标签配合${变量}占位符，Java后端把数据塞进ModelAndView后返回视图名，Freemarker自动渲染出完整页面。

我最早用JSP的时候，最大的痛点是JSP里能写Java代码，团队里有人图省事就把复杂逻辑塞进页面，几个月后页面里全是脚本片段，查个bug得翻半天。Freemarker的模板语法非常克制，只能输出数据和调用一些简单的格式化函数，不能在模板里写业务代码，这就倒逼你把逻辑留在Service层。与此同时，Freemarker的HTML页面可以直接用浏览器打开调试样式，不像JSP那样必须启动容器才能看到效果，对于前端样式调整来说方便很多。

不过Freemarker也有需要注意的地方：默认情况下它不允许访问Java对象内部私有属性，需要开启freemarker.settings.boolean_format之类的配置，或者干脆为每个实体准备对应的VO类。我这里的建议是，给工资展示单独建VO类，比如SalaryDetailVO，把员工名、部门名、岗位名、绩效等级、实发金额这些字段提前拼接好，模板只做展示逻辑，不需要访问关联对象，这样模板干净，前端也轻松。

2.4 Maven在项目生命周期中的角色

Maven承担了依赖管理和构建打包两件事。SpringBoot项目一创建，就会引用大量的第三方依赖，要是没有Maven管着，光是版本冲突就够你喝一壶。Maven的传递性依赖机制能自动解决大部分冲突，我们只需要在pom.xml里指定核心依赖的版本，比如SpringBoot父工程通常用2.7.x或3.x，其中2.7.x还在用javax命名空间，适配JDK 8，适合绝大多数旧项目；3.x则切换到jakarta命名空间，需要JDK 17以上。如果你的机器还是JDK 8，就老老实实选2.7.x。

Maven构建时我还习惯用finalName指定打包后的文件名，避免默认带版本号的长名称。部署脚本里java -jar salary-system.jar也比带着版本号的Jar更省心。Maven还有一个优点——mvn clean package会自动执行测试代码，如果没写测试就跳过，这能保证每次打包出的artifact是干净的。

3. 数据库设计与核心业务思路

3.1 实体关系模型

整个系统围绕员工表和工资核算这条主线展开。按照我习惯的设计顺序，先画核心关系再定表：

• 员工表（employee）：员工编号（工号）、姓名、性别、生日、入职日期、部门ID、岗位ID、状态（在职/离职）、联系电话、紧急联系人。
• 部门表（department）：部门ID、部门名称、上级部门ID、部门负责人。
• 岗位表（position）：岗位ID、岗位名称、所属部门ID、基础工资、工资区间上限下限。
• 绩效指标表（performance_metric）：指标ID、指标名称、指标类型（月度/季度）、满分值、权重。
• 绩效评分表（performance_score）：评分ID、员工ID、指标ID、评分月份、评分值、评分人。
• 工资配置表（salary_config）：配置ID、员工ID、基本工资、岗位工资、补贴、社保基数、公积金基数、个税起征点。
• 工资月度表（salary_monthly）：记录ID、员工ID、薪资月份、基础工资、绩效工资、加班费、补贴、扣款合计、应发工资、个税、实发工资、核算状态。

重点说一下员工表和工资表的关系。员工表的部分字段（部门、岗位）是从部门表、岗位表里引用的外键。在职员工才能做绩效评分和工资核算，离职员工保留历史数据但不再参与月度计算。绩效分表和月度工资表都通过员工ID关联，这样可以随时查出某个员工过去六个月的绩效曲线和工资变化。

3.2 工资核算规则的设定与扩展

工资核算决定了这个系统能不能真正用起来，不同的企业核算规则千差万别。我实现了一个尽量灵活的方案：在工资配置表里维护每个员工的固定项，然后在工资月度表中计算动态项。

固定项包括基本工资、岗位工资、交通补贴、餐饮补贴、全勤奖，以及社保和公积金的个人缴纳部分。这些数据通常在员工入职时确定，之后根据调薪记录调整。动态项主要是绩效工资、加班工资和各类扣款。绩效工资由绩效分决定，常见的公式是：

• 绩效工资 = 绩效基数 × 绩效系数
• 绩效系数 = 绩效得分 / 100，但通常有上下限，比如0.6到1.5之间。
• 绩效基数 = 基本工资 × 30%

还有一类企业用的是阶梯绩效制，比如得分在90分以上按1.2倍发，80到89按1.0倍，60到79按0.8倍，60分以下按0.5倍。这两种方案我都在代码里做了抽象：先算原始分数，再套系数规则，最后乘以基数得出绩效工资。实际实施中你可以在SalaryCalculator类里预定义两种策略，根据员工所属岗位类型去匹配，加新规则时只需要扩展一个策略实现，不会影响主流程。

工资表的核算状态我用了一个字段标记：0未核算，1已核算，2已确认。每个月生成工资数据时会先检查目标月份是否已经核算过，如果是则拒绝重复生成，防止误操作覆盖历史数据。等HR确认无误后把状态改为已确认，状态锁死后这行数据就不再允许被普通操作修改。这个设计虽然简单，但真能避免很多麻烦。

3.3 数据库索引与性能兜底

企业员工数通常不会特别大，几千条到几万条数据是常态，但月末工资核算时会对整个月的员工表做一遍连接查询，如果没有合适的索引，慢查询就会很明显。我在这些字段上建了索引：

• employee表：dept_id、position_id、status
• performance_score表：employee_id、score_month
• salary_monthly表：employee_id、salary_month
• salary_config表：employee_id

这样工资核算的典型SQL会根据员工ID和月份两个维度做索引定位，速度极快。哪怕以后员工量涨到几十万，只要索引合理，加上分页查询，MySQL也扛得住。

4. 核心模块的实操实现

4.1 项目骨架与依赖配置

创建项目的步骤可以很固定。用Maven新建一个工程，然后在pom.xml里引入SpringBoot相关依赖：

<parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.7.18</version> <relativePath/> </parent> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-freemarker</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-jdbc</artifactId> </dependency> <dependency> <groupId>org.mybatis.spring.boot</groupId> <artifactId>mybatis-spring-boot-starter</artifactId> <version>2.3.1</version> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>8.0.33</version> </dependency> <dependency> <groupId>com.github.pagehelper</groupId> <artifactId>pagehelper-spring-boot-starter</artifactId> <version>1.4.7</version> </dependency> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <optional>true</optional> </dependency> </dependencies>

这几项依赖的坑我会一个个说。mybatis-spring-boot-starter默认从2.3.1起会做自动配置，但不带分页插件，所以引入PageHelper辅助做分页。lombok能省去一堆getter/setter，不过在大型项目中有人不太喜欢它，因为它会在编译期生成代码、调试时不容易跳到真实实现，但对于这个项目来说完全够用。

application.yml记得配置数据源和Freemarker视图解析器：

server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/salary_system?useUnicode=true&characterEncoding=utf8mb4&serverTimezone=Asia/Shanghai username: root password: yourpassword driver-class-name: com.mysql.cj.jdbc.Driver freemarker: suffix: .ftl template-loader-path: classpath:/templates/ cache: false mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.example.salary.entity configuration: map-underscore-to-camel-case: true

map-underscore-to-camel-case这个配置很关键，数据库字段的dept_id能自动映射到Java属性的deptId，不用手写一堆resultMap。

4.2 实体类与通用Mapper实践

和MyBatis的XML里手动写SQL不同，这个项目的Mapper层我建议只写必要的方法。一是因为像根据ID查、根据主键更新、插入这些都是极其标准的方法，手写纯属浪费时间；二是复杂的查询（比如多表关联、动态条件）用XML写更清晰，Java注解写长SQL反而可读性差。

以一个员工信息分页查询为例：

public interface EmployeeMapper { List<EmployeeVO> selectEmployeePage(@Param("keyword") String keyword, @Param("deptId") Integer deptId, @Param("status") Integer status); EmployeeVO selectEmployeeDetail(@Param("id") Integer id); int insertEmployee(Employee employee); int updateEmployee(Employee employee); int updateStatus(@Param("id") Integer id, @Param("status") Integer status); }

对应的XML里采用动态SQL，效果类似于：

<select id="selectEmployeePage" resultType="com.example.salary.vo.EmployeeVO"> SELECT e.id, e.emp_no, e.name, e.gender, e.birthday, e.hire_date, d.name AS dept_name, p.name AS position_name, e.status FROM employee e LEFT JOIN department d ON e.dept_id = d.id LEFT JOIN position p ON e.position_id = p.id <where> <if test="keyword != null and keyword != ''"> AND (e.name LIKE CONCAT('%', #{keyword}, '%') OR e.emp_no LIKE CONCAT('%', #{keyword}, '%')) </if> <if test="deptId != null"> AND e.dept_id = #{deptId} </if> <if test="status != null"> AND e.status = #{status} </if> </where> ORDER BY e.id DESC </select>

动态SQL用<where>标签会自动去掉第一条多余的AND，很多新手在这里踩坑——写成了WHERE 1=1之类的拼接。WHERE 1=1不是不能用，但会破坏索引扫描的优化空间，所以能少用就少用。我的原则：XML里只写无法自动生成或需要联表查询的SQL，简单的单表CRUD一律在Java里复用基础Mapper方法。

4.3 登录认证与权限拦截

企业内部的系统，安全策略要平衡简单和有效。我这里是基于Session的登录方案：用户名密码校验成功后，把用户对象放进Session。然后用Spring的HandlerInterceptor做拦截，定义两个注解@LoginRequired和@RoleRequired，也可以简单到只判断路径前缀，比如/admin/**必须管理员权限，/hr/**需要HR权限。

具体的拦截器逻辑：

@Component public class AuthInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { if (!(handler instanceof HandlerMethod)) { return true; } User user = (User) request.getSession().getAttribute("loginUser"); if (user == null) { response.sendRedirect("/login"); return false; } // 简单角色校验，使用注解的role属性 HandlerMethod handlerMethod = (HandlerMethod) handler; RoleRequired roleRequired = handlerMethod.getMethodAnnotation(RoleRequired.class); if (roleRequired != null) { String requiredRole = roleRequired.value(); if (!user.getRole().equals(requiredRole)) { response.sendError(403); return false; } } return true; } }

登录密码存储不能明文，至少要用MD5加盐，更推荐BCrypt。Spring Security里自带BCryptPasswordEncoder，但只在登录这里用的话，引入全部Security配置又会牵扯到过滤链，重了一截。所以我选择单独引入spring-security-crypto依赖，只用它的BCrypt工具类做密码哈希和校验。这种方式轻量、无侵入，也足够安全。

4.4 工资核算的Service层设计

工资核算模块是这个系统的核心，我把它单独抽象成一个核算服务：

public class SalaryCalculationService { @Transactional(rollbackFor = Exception.class) public boolean generateMonthlySalary(String salaryMonth) { // 1. 检查该月份是否已经核算过 if (salaryMapper.countByMonth(salaryMonth) > 0) { throw new RuntimeException("该月份工资已核算，禁止重复生成"); } // 2. 查询所有在职员工 List<Employee> employees = employeeMapper.selectByStatus(1); for (Employee emp : employees) { // 3. 获取工资配置 SalaryConfig config = salaryConfigMapper.selectByEmployeeId(emp.getId()); if (config == null) { throw new RuntimeException("员工【" + emp.getName() + "】未配置工资项"); } // 4. 计算绩效工资 BigDecimal performanceSalary = calcPerformanceSalary(emp.getId(), salaryMonth, config); // 5. 组装月度工资明细 SalaryMonthly monthly = buildMonthlySalary(emp, config, performanceSalary, salaryMonth); // 6. 单条插入，积累大事务 salaryMapper.insert(monthly); } return true; } }

这里有个非常重要的实操细节：大批量插入时不要一个for循环里反复commit，但也别让一个人几千条数据的插入全部套在一个超长事务里。MySQL的默认隔离级别是REPEATABLE READ，长事务会影响锁的释放和undo log的清理，所以核算时采用每插入一批（比如100条）提交一次，而不是所有员工一次全部提交。

另外算个税时，不同城市的起征点和税率表略有差异，我把税率表放在一个配置类里，方便调整。个税算法沿用经典的累进税率，工资金额超过5000元的部分逐级计算，代码里可以用简单的if/else实现，也可以预先定义税率区间列表循环计算。

4.5 Excel批量导入导出

工资系统里大量历史数据都在Excel里，手工一条条录绝对浪费时间。我用了Apache POI的XSSFWorkbook来处理Excel 2007以上的xlsx文件。批量导入员工信息的步骤：

1. 上传文件到临时目录，解析为Workbook。
2. 遍历第一个Sheet的每一行，做字段格式校验，比如工号不能为空、日期格式是否正确、基本工资是否为数字。
3. 校验通过后分批insert，每100条flush一次。
4. 生成导入报告，标明第几行哪列错了，方便HR去修正。

导出工资表时同理，把salary_monthly表按照月份查出来，构建Excel行，另存为下载。我习惯给导出操作加一个"正在生成，请稍后刷新"的异步提示。因为数据量大时POI会比较吃内存，同步请求容易超时，改成后台线程生成文件、生成完成后页面轮询获取结果更稳妥。这是实践得出的教训，刚开始用同步导出，几百人的工资表没问题，等到了上千人加上复杂表头样式，接口响应轻松超过10秒，用户早就以为系统挂了。

5. 常见问题与排查技巧实录

5.1 数据库连接时区导致的日期错乱

只要是直接用serverTimezone=Asia/Shanghai就能解决大多数问题。但有时候开发机和服务器时区不一致，部署后出现日期少一天的情况，多半是因为JDBC驱动连接串里没加时区参数。另外MySQL 8.0的驱动类是com.mysql.cj.jdbc.Driver，如果还在沿用旧的com.mysql.jdbc.Driver，会直接报ClassNotFound。这点在切换到新驱动时一定要注意。

5.2 Freemarker模板变量为null导致渲染失败

Freemarker的一个特色是，默认情况下如果模板里引用一个不存在的变量，它会直接抛异常，而不是像JSP那样显示空白。这个特性逼着你把数据查全或提前判空。我在做员工详情页时，本来有些员工没有岗位信息，模板里${emp.positionName}就是null，页面直接500，排查半天才发现是缺这个字段。

解决方案有三种：一是在SQL里用LEFT JOIN保证position_name至少是空字符串；二是在VO里给默认值；三是在模板里使用${emp.positionName!''}这样的空值处理。我最终还是倾向于第一种，前端模板永远不做复杂的判空逻辑，因为把气力花在模板上远不如在数据源头掐死问题。

5.3 大批量导入Excel时的内存溢出

用POI的时候，如果直接用new XSSFWorkbook(inputStream)读取一个几十MB的Excel，JVM堆内存很容易被撑爆。解决方式是使用SXSSFWorkbook来写，或者读取时用XSSFWorkbook改成SAX (Event API)解析，甚至可以提前用StreamingReader包装输入流。但其实最实用的是：把上传文件的大小限制在10MB以内，超过就提示用户按月份拆分上传。企业月度工资Excel通常不会到几十MB，设置一个合理上限比处理大文件省心得多。

5.4 MyBatis分页插件查询总数慢

PageHelper用起来方便，但如果查询的SQL里带了LEFT JOIN和大量关联表，count语句可能执行得很慢。我在绩效评分明细页遇到过这个问题，一页10条数据，查总数花了2秒多。排查后发现count里也执行了不必要的join。优化手段是在Mapper的count语句上手动重写，只统计主表行数，或者给关联表的条件加索引。PageHelper提供了countSuffix参数可以指向一个自定义的count查询，必要时直接用。不过大多数场景下，给外键字段和过滤条件建好索引后，这个问题不会出现。

5.5 跨域与Session丢失

虽然这是个传统的服务端渲染项目，前后端同源不会触发跨域，但如果后来改造接口给移动端用，就一定会遇到跨域和Session丢失的问题。我曾经的踩坑经历：先配置了@CrossOrigin允许所有来源，但请求带Cookie时还是不生效。原因是@CrossOrigin默认不开启allowCredentials=true，必须显式设置，而且前端请求得标注withCredentials: true。如果改成前后端分离结构，还需要在使用JWT抵扣Session，或单独做单点登录，这点在演进时一定要提前规划。

6. 部署方案与后续扩展建议

6.1 从开发到生产的部署流程

SpringBoot的部署友好性是我喜欢它的重要原因。用mvn clean package -DskipTests打出Jar包，传到服务器，执行：

java -jar salary-system.jar --spring.profiles.active=prod

生产环境配置放在application-prod.yml里，数据库地址改为内网IP，加上日志路径、线程池参数等。如果有反向代理（比如Nginx），将80端口的请求转发到8080即可。

如果是小企业没有独立服务器，也可以部署在一台普通PC或者云主机上，MySQL和Jar包共存。内存建议至少2GB，JVM启动参数可以设-Xms512m -Xmx1024m，毕竟工资系统对性能的压测不需要像电商那样苛刻。定期备份MySQL数据才是重中之重，我习惯每天凌晨用cron执行：

mysqldump -u root -p salary_system > /backup/salary_$(date +%F).sql

备份文件保留30天，云平台也可以开启自动快照。

6.2 模块扩展与现实边界

这个系统已经能覆盖为核心功能，但要真正落地到不同的公司，还需要根据实际情况做定制。最常见的扩展是考勤数据对接：把考勤机导出的打卡Excel导入，系统自动统计迟到早退天数，再通过工资配置里的考勤扣款规则，自动算进工资表。这比手填扣款字段要准确得多。

还有一个实用的扩展是工资条自助查看。可以为每个员工生成独立账号，登录后只能看到自己的工资明细，配合PDF导出，能在很大程度上解放HR的发薪沟通成本。当然要做这个，需要把握权限控制，防止水平权限越权——比如A员工通过修改URL里的员工ID参数查看B员工的工资条，这是最常见的漏洞。我的建议是所有查询接口都用Session里的员工ID去过滤，而不是相信前端传上来的参数。

6.3 这个项目能给你带来什么

无论是用于毕设、简历项目还是真实企业落地，这套基于JavaWeb + SpringBoot + Freemarker + MySQL + Maven的绩效工资系统，都是技术与业务结合很好的实训素材。它不像简单CRUD项目那样只增删改查，而是加入了复杂核算逻辑、权限控制、事务管理、批量导入导出、报表查询，这些都是企业开发的高频命门。你把它弄懂，就等于把大部分单体管理系统的基本盘握在手里了。

我个人的一点体会是：做这类项目时，不要只盯着代码量。很多人喜欢把精力花在花哨的页面效果上，却对工资计算规则一知半解。真正的价值在于理解业务——为什么绩效系数要设上下限，为什么工资核算要锁定状态防止篡改，为什么导出的Excel表头要比员工手里拿到的工资条多出哪些字段。技术会更新换代，但你对业务的理解和建模思路，才是这个项目带给你的核心资产。如果你接下来打算做类似系统，可以把我的这套表结构设计和核算思路当作起点，然后结合自己公司或课题的实际规则去调整，相信会比照着网上别人写好的代码直接复制有用得多。