SpringBoot+Vue企业绩效管理系统：从数据库设计到部署答辩全流程实战

写这篇文章之前，我刚好又收到一条私信：大三学生，想找一套能写进简历、又能顺利通过毕设答辩的项目，问我 SpringBoot + Vue 的企业内部绩效管理系统到底能不能做、值不值得做。这个问题我被问过太多次了，借着这篇博客把整套思路一次讲透。如果你正准备做毕设、课设，或者想用一套 Java + MySQL + SpringBoot + Vue 的完整项目来练手，下面这些内容可以直接当参考。

先说结论：这套题的性价比很高，但它不是那种"抄一遍就跑"的 CRUD 项目。绩效量化系统的核心难点不在功能多少，而在业务闭环是否合理——指标怎么配置、分数怎么计算、历史评分怎么保存、报表怎么统计，每一个环节都得能"讲出道理"。这篇文章就按照我实际搭建这套系统时的思路，把数据库设计、后端接口、前端交互、量化算法、部署答辩全流程整理出来，尽量做到你照着做能少走弯路。

1. 为什么这套系统适合毕设和课设：选题价值与技术收益的双重考量

1.1 从评审老师的视角看绩效系统的独特优势

很多同学选题时有个误区：总觉得系统越复杂越好，于是选了什么"大型电商平台""智慧校园全平台"，结果做了三个月连核心模块都没跑通。毕设和课设的评审，看重的从来不是功能数量，而是"你对你做的事情有没有完整的理解"。绩效量化管理系统在这方面天生占便宜，因为它的业务逻辑足够成体系，又不至于超出个人开发能力的天花板。

企业绩效管理的标准闭环是：目标设定 -> 过程跟踪 -> 考核评分 -> 结果反馈 -> 数据复盘。你把它落地成系统，就自然有了指标配置、考核周期管理、评分打分、成绩统计、可视化报表这几个核心功能。这个业务链条是真实存在的，不是编造出来的，所以答辩时老师问"这个系统解决什么问题"，你能很清楚地回答：它把企业里原本用 Excel 表格流转的绩效数据，变成了一个可追溯、可统计、权限清晰的管理工具。

从加分项来说，绩效系统还有一个其他管理系统不具备的优势：它天然涉及"量化计算"。这意味着你可以名正言顺地引入权重算法、等级判定、趋势分析，而不是只做增删改查。这两年在企业做技术面试，我也明显感觉到，面试官对纯 CRUD 项目已经不太感冒，而带业务计算和数据分析味道的项目，聊起来信息量更大。

1.2 一套系统覆盖的主流技术栈清单

这套系统能练到的技术点，基本就是国内中小型公司 Java 后端的主流标配了。拿我自己搭的版本来举例：

后端以 SpringBoot 2.7.x 为底座，持久层用 MyBatis-Plus（最新 3.5.x），数据库选 MySQL 8.0。认证授权的部分用了 JWT + 拦截器，这算是现在前后端分离项目最常用的无状态方案。数据导入导出用 EasyExcel，理由很直接：POI 原生 API 写起来太啰嗦，EasyExcel 对内存优化更好，导入上万条员工数据不会卡死。

前端我用的是 Vue 3 + Element Plus + Pinia + ECharts，搭配 Vite 构建。如果你们学校的课程资源还停留在 Vue 2 + Element UI，也没关系，核心思路完全一致，只是 API 的写法略有差异（比如 Vue 3 里 this.$router 变成了 useRouter()）。Vue Router 做动态路由（按登录人的角色加载菜单），Axios 做请求拦截（统一携带 Token、统一处理 401），ECharts 画报表大屏。这些小点单独拎出来，每一个都能在简历上写一笔。

还有个容易被忽略的点：这套项目是完全前后端分离的，部署时前端打包成静态文件、后端打成 jar 包，你可以用 Nginx 或者直接把前端静态文件放进 SpringBoot 的 static 目录。两种方式我都试过，后一种最省事，适合本地演示；前一种更接近企业真实部署，适合技术面试的时候吹。

1.3 项目规模控制：为什么这个体量刚好合适

毕设最怕什么？最怕做不完。绩效管理系统在规模上恰好卡在一个舒服的位置：单人可以搞定全部模块，代码量也就是中大型课程设计的量级。我粗略统计过自己那份参考源码，后端 Java 文件在 60 到 80 个之间，前端 Vue 组件在 25 到 35 个之间，正常节奏一个月能稳扎稳打做完，两个月的周期可以很从容地打磨细节。

功能模块也不需要贪多。核心五块就够：登录认证、组织架构（部门 + 员工管理）、绩效指标配置、考核周期与评分、统计报表。如果还有余力，可以加个人中心、消息通知、操作日志，这些都是可以独立扩展的点。关键是先把主流程跑通，再考虑锦上添花，不要上来就设计一个"无所不包"的大系统，最后什么都做不深入。

2. 系统总体架构与功能边界：动手写代码前必须先想清楚的事

2.1 前后端分离架构与目录规划

我见过太多同学拿到项目后，第一步就急着建表、写接口，结果写到一半发现模块边界一塌糊涂：用户管理里塞了评分逻辑，评分接口里又混着部门查询。所以这里我建议，动手前先花半天时间把目录结构和模块职责定下来。

后端推荐按职责分包，而不是按表分包。直接给一个我实际使用的结构作为参考：

code复制com.company.performance
├── controller          // 控制层，只负责参数接收和返回
│   ├── auth            // 登录认证相关
│   ├── system          // 部门、用户、角色、菜单
│   ├── assess          // 指标、周期、评分
│   └── report          // 统计报表
├── service             // 业务层，核心计算都在这层
├── mapper              // MyBatis-Plus 的 Mapper 接口
├── entity              // 数据库实体
├── dto                 // 前端交互参数对象，避免实体直接暴露
├── config              // 配置类：拦截器、跨域、分页插件、JSON序列化
├── common             // 统一返回结果、异常处理、工具类
└── annotation         // 自定义注解（比如权限校验、操作日志）

前端目录对应：

code复制src
├── api                 // 每个模块一个 api 文件，统一封装 Axios 请求
├── router              // 路由配置，包含静态路由和动态路由
├── store               // Pinia 状态管理：用户信息、Token、菜单权限
├── views               // 页面组件，按模块分子目录
├── components          // 公共组件（上传、富文本、图表封装等）
├── utils               // 工具类：request.js 封装的 axios 实例等
└── layout              // 主框架布局、侧边栏、顶栏

这样划分有一个明显好处：后面写接口时，你很清楚某个逻辑该放 controller 还是 service。比如"评分时计算总分"，controller 层只接收 { userId, periodId, scores: [] }，真正算分、校验、落库全部放到 service 层，这样单元测试也好写，答辩时讲"业务层与表现层分离"也有实例支撑。

2.2 核心业务模块与角色权限模型

模块划分直接决定你建几张表、写几个接口。我的设计是五个核心模块：

角色权限分三种：系统管理员（admin）、部门主管（manager）、普通员工（user）。这里要稍微多花点心思设计，因为权限模型是否合理是答辩高频考点。我用的方案是标准的 RBAC：用户表关联角色表，角色关联菜单权限表，后端接口通过拦截器 + 自定义注解双重控制。管理员能配置指标、管理用户、查看全公司报表；主管能对本部门下属打分、查看本部门统计；普通员工只能查看自己的绩效结果和个人得分明细。

这套模型在代码层面落地的时候，注意接口权限用角色编码做校验，不要用死板的用户名硬编码。比如打分接口用 @PreAuthorize("hasRole('MANAGER')")，或者在拦截器里检验当前用户的角色列表。SpringBoot 的 Spring Security 是一个选择，但对课程设计来说太重了，我建议用简单的拦截器方案就够，也更容易跟老师解释清楚。

2.3 一个容易被忽略的设计：菜单权限与动态路由

很多毕设项目的权限只做到了"接口不让你调"，但前端的菜单还挂在那里，点进去才报 401。这很不专业。真正的做法是：登录成功后，前端调用 /auth/userinfo 接口，后端返回该用户的菜单树（从数据库菜单表查出来），前端用 Vue Router 的 router.addRoute() 动态挂载路由，没有权限的页面压根不会出现在侧边栏。

菜单树的结构用父子级关系存储：parent_id 为 0 表示一级菜单，每个菜单项包含 路由路径、组件地址、菜单名称、图标、排序。前端拿到这个数组后，递归转换成路由配置。这块逻辑不复杂，但需要你理解 Vue Router 的 API，建议专门用一个模块来封装，不要散落在页面里。

3. 数据库模型设计：绩效数据怎么落库才经得起推敲

3.1 核心表结构与关系梳理

数据库设计是整个系统里最值得花时间的环节。我见过太多项目把"绩效得分"直接设计成一个字段挂在员工表上，这是典型的错误——一次考核结束后，下个周期再打分就把历史覆盖了，系统完全丧失追溯能力。正确的做法是"考核周期"和"评分快照"独立建表。

我给出实际项目中验证过的核心表清单：

• sys_department：部门表，字段包括 id、部门名称、负责人 id、父部门 id、排序。
• sys_user：用户/员工表，字段包括 id、工号、姓名、密码（BCrypt 加密）、部门 id、角色 id、邮箱、手机号、入职时间、状态。
• sys_role / sys_menu：角色表与菜单权限表，多对多关联用 sys_role_menu 中间表。
• assess_period：考核周期表，字段包括 id、周期名称（如"2025年一季度"）、开始日期、结束日期、评分状态（未开始/进行中/已结束）、创建人。
• assess_indicator：考核指标表，字段包括 id、指标名称（如"任务完成率"）、所属维度（业绩/能力/态度/协作）、指标说明、数据来源、默认权重。
• assess_score：主评分表，一条记录代表"某个员工在某个考核周期的总评分"，字段包括 id、员工 id、周期 id、评分人 id、综合得分、评级、评语、提交时间。
• assess_score_detail：评分明细表，字段包括 id、主评分 id、指标 id、指标名称（冗余）、指标得分、指标权重。为什么冗余指标名称和权重？因为指标和权重后续可能被管理员修改，而历史评分必须保留当时的快照，否则历史数据就失真了。

code复制注意，assess_score_detail 这个设计是整个系统数据层最关键的细节。如果你只存主表的总分，老师一句"那我想看具体哪项扣了分怎么办"就能让你愣住。有了明细表，用户点开历史评分，可以完整看到每项指标的得分、权重和评语。这也是"量化"两个字的落地。

3.2 关键字段的约束与索引设计

索引这块看似基础，但很多课程设计根本不做，导致数据量一大查询就很慢。绩效系统里最常出现的查询是：按考核周期查某个部门所有员工的得分、按员工查历史各周期得分。所以至少加两组索引：

• assess_score 表：(period_id, user_id) 加唯一索引，防止同一个人在同一周期被重复评分；(user_id) 普通索引，用于个人历史趋势查询。
• assess_score_detail 表：(score_id) 普通索引，用于反查明细；(indicator_id) 普通索引，可用来统计某指标在所有部门的平均得分。

时间字段统一用 datetime 类型，不要用 varchar 直接存字符串，否则你后面做"按月统计平均分"这类 SQL 会非常痛苦。MySQL 原生的日期函数在 varchar 上无法正确使用索引。

3.3 用一段建表 SQL 串起整个核心逻辑

直接看一组简化的核心建表语句，你照着改就能用：

sql复制CREATE TABLE `assess_period` (
  `id` bigint NOT NULL AUTO_INCREMENT,
  `period_name` varchar(64) NOT NULL COMMENT '周期名称，如2025年Q1',
  `start_date` date NOT NULL,
  `end_date` date NOT NULL,
  `status` tinyint NOT NULL DEFAULT '0' COMMENT '0未开始 1进行中 2已结束',
  `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='考核周期表';

CREATE TABLE `assess_score` (
  `id` bigint NOT NULL AUTO_INCREMENT,
  `user_id` bigint NOT NULL COMMENT '被评员工ID',
  `period_id` bigint NOT NULL COMMENT '考核周期ID',
  `scorer_id` bigint NOT NULL COMMENT '评分人ID',
  `total_score` decimal(5,2) NOT NULL COMMENT '综合得分',
  `rating` varchar(8) NOT NULL COMMENT '评级：S/A/B/C/D',
  `comment` varchar(500) DEFAULT NULL COMMENT '考核评语',
  `submit_time` datetime NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_period_user` (`period_id`,`user_id`),
  KEY `idx_user` (`user_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='考核主评分表';

这里有个细节要提一下：总分的字段类型别用 double，用 decimal(5,2)。绩效分数往往要求精确到小数点后两位，decimal 能避免浮点数精度误差。你去算"0.1 + 0.2"的时候会发现在 Java 里结果是 0.30000000000000004，这在做资金、分数相关系统时是不可接受的。

4. 后端核心实现思路：从认证到统计分析的完整链路

4.1 JWT 登录认证与拦截器设计

登录接口的逻辑并不复杂：接收用户名密码 -> 先查出用户 -> BCryptPasswordEncoder 校验密码 -> 登录成功生成 JWT 返回前端。关键点是 Token 里放什么。我的做法是只放 userId 和 loginName，不把角色、权限全部塞进去，因为用户角色可能被管理员调整，而 JWT 是有有效期且不可撤销的，塞得太满会导致"角色改了但 Token 还是旧的"的尴尬。

拦截器的思路要清晰：

java复制public class AuthInterceptor implements HandlerInterceptor {
    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        // 1. 放行登录接口和静态资源
        if (isWhitelist(request.getRequestURI())) {
            return true;
        }
        // 2. 取 Header 中的 Authorization: Bearer <token>
        String token = resolveToken(request);
        if (token == null || !jwtUtil.verify(token)) {
            return renderUnauthorized(response);
        }
        // 3. 把 userId 放入 ThreadLocal（或 request attribute），供后续业务使用
        Long userId = jwtUtil.getUserId(token);
        UserContext.set(userId);
        return true;
    }
}

校验收尾之后记得在后置拦截器 afterCompletion 里清空 ThreadLocal，否则线程池复用会导致用户数据串号。这个坑我踩过，排查了很久才发现是 ThreadLocal 没清理，好在答辩前解决了，现在写出来提醒你。

还有跨域问题。前后端分离项目，前端项目跑在 http://localhost:5173，后端是 http://localhost:8080，协议和端口都不同，浏览器会直接拦截。简单方案是在 SpringBoot 里实现一个 WebMvcConfigurer 添加全局跨域配置；开发期也可以在前端 Vite 配置 proxy 代理转发。部署阶段如果前后端同域，跨域问题就不存在了。

4.2 统一返回结构与全局异常处理

这个属于基本功，但在课程设计里特别加分。我推荐定义统一的返回结果类 Result<T>，包含三个字段：code、message、data。所有接口都返回这个结构，前端 Axios 拦截器统一处理。举个例子：

java复制public class Result<T> {
    private Integer code;      // 200成功，400业务错误，401未登录，500系统异常
    private String message;
    private T data;
}

全局异常处理用 @RestControllerAdvice，把所有可能抛出的业务异常、参数校验异常、数据库异常全部收口，而不是让用户看到一堆英文堆栈信息。像"该员工在当前周期已被评分"这种业务提示，直接用自定义业务异常 BusinessException 抛出，由全局处理器转成 code=400 返回给前端提示。

这一套下来代码量不大，但答辩时老师问"系统如何处理异常"你就有了非常清晰的回答路径。

4.3 绩效数据的统计分析：这条 SQL 是核心中的核心

评分数据存好了，报表需求自然会来。最典型的是"部门平均分随周期变化趋势"。直接看这条核心 SQL：

sql复制SELECT
    p.period_name,
    d.dept_name,
    ROUND(AVG(s.total_score), 2) AS avg_score
FROM assess_score s
JOIN assess_period p ON s.period_id = p.id
JOIN sys_user u ON s.user_id = u.id
JOIN sys_department d ON u.dept_id = d.id
WHERE d.id = #{deptId}
GROUP BY p.id, d.id
ORDER BY p.start_date;

这条 SQL 的 join 链路是：成绩表 -> 周期表 -> 用户表 -> 部门表，逻辑一目了然。如果部门层级是多级的，最简单是加一个逻辑字段记录所有上级部门 id 集合（比如 ancestors 字段存 "1,3,7"），查询时用 FIND_IN_SET 来找。这个方案虽然不完美，但比递归查询简单得多，也足够课程设计用了。

榜单类的需求，比如"查看本部门员工本期得分排名"，用窗口函数 ROW_NUMBER() OVER (PARTITION BY d.id ORDER BY s.total_score DESC) 在 MySQL 8.0 里可以直接实现。如果用的是 MySQL 5.7，就得靠子查询 + 用户变量模拟，太麻烦，建议直接上 8.0。

4.4 实战中的加分项：EasyExcel 导入员工数据

绩效系统必然面临一个冷启动问题：几十上百个员工，不可能一个一个在页面上手动添加。所以"管理员下载 Excel 模板 -> 填好员工信息 -> 批量导入系统"这个功能非常加分。EasyExcel 的用法也很简单，定义一个 UserImportDTO，字段上加 @ExcelProperty("姓名") 注解，然后用 EasyExcel.read(inputStream).sheet().head(UserImportDTO.class).doReadSync() 就能一次性读出来。

注意导入时要做的三层校验：数据格式校验（手机号正则、日期格式）、业务校验（工号是否重复、部门是否存在）、重复数据校验（同一文件内重复）。导入结果要给出"成功 N 条、失败 M 条及失败原因"，不然管理员根本不知道谁没导进去。

4.5 再加两个小而稳的亮点

除了上面这些核心逻辑，还有两个小功能建议实现，成本很低但对答辩效果很好：

第一个是全局 XSS 过滤。用一个 Filter 拦截所有 POST 和查询参数，把 <script> 之类的危险内容转义掉。很多课程设计完全不管 XSS，你做了就比别人多一个安全加分点。第二个是操作日志。用 Spring AOP + 自定义注解 @Log("删除用户") 实现，每次重要操作记录操作人、操作时间、请求参数、IP。虽然这不是绩效系统的必备功能，但越接近企业真实系统的细节，越能在答辩和技术面试里体现出工程素养。

5. 前端核心实现：动态路由、评分交互与可视化报表

5.1 Axios 封装与请求拦截

前端这块的第一件事是封装 utils/request.js，它是所有请求的总入口。统一做三件事：

• 从 Pinia store 里取出 Token，加到请求头的 Authorization。
• 响应拦截器里如果发现返回的 code 是 401，就清空本地状态并跳转登录页。
• 如果 code 是 400，直接弹出 Element Plus 的 ElMessage 显示后端返回的 message，不需要每个页面单独写错误处理。

javascript复制request.interceptors.request.use(config => {
  const token = useUserStore().token;
  if (token) {
    config.headers.Authorization = `Bearer ${token}`;
  }
  return config;
});

request.interceptors.response.use(
  response => {
    const res = response.data;
    if (res.code === 401) {
      useUserStore().logout();
      router.push('/login');
    }
    if (res.code !== 200) {
      ElMessage.error(res.message || '请求出错');
      return Promise.reject(new Error(res.message));
    }
    return res;
  },
  error => Promise.reject(error)
);

顺便说一句，接口返回体里如果直接返回了完整的 Result 结构，前端拿到 response.data 之后再去 res.data 拿真正的业务数据就可以了，不用每一层都剥壳。这种规范化对后期维护价值很大。

5.2 动态菜单与权限路由的落地

登录完成后调 /auth/userinfo，返回结构大概是：

json复制{
  "userInfo": { "id": 1, "username": "admin", "realName": "张三" },
  "roles": ["ADMIN"],
  "menus": [
    { "id": 1, "path": "/dashboard", "component": "Dashboard", "name": "首页", "icon": "HomeFilled" },
    { "id": 2, "path": "/assess", "component": "Layout", "name": "考核管理", "children": [...] }
  ]
}

前端拿到 menus 后，用字典把"组件地址字符串"映射到真正 import 进来的组件，然后通过 router.addRoute() 动态添加。这里最容易踩的坑是：页面刷新后 Pinia 里的状态是全空的，动态路由也就丢了。解决办法是在路由守卫 router.beforeEach 里做"首次刷新时重新获取用户信息并重新注册路由"，然后通过 next 函数继续放行。这个逻辑流程写不对，刷新页面就白屏。

5.3 评分模块的交互设计：主管打分的实操细节

评分页面是这套系统里最有"业务感"的页面。主管登录后，先选择考核周期，然后看到自己的下属列表。每个下属点进去之后，会出现一张评分表单，展示每个指标名称、指标说明、权重以及得分输入框。这里有几个交互细节要做到位：

• 前端要实时计算加权总分并展示，让主管在填完所有指标后立刻看到总分。这个体验远比"先填完再提交才能看到分数"好。
• 如果某个周期已经处于"已结束"状态，页面必须整体锁定，不能让人还能提交评分。
• 给已提交的目标打特殊标识（比如"已评分"按钮状态），方便主管确认进度。

提交时的数据格式设计成 { periodId, userId, scorerId, comment, detailList: [{ indicatorId, score, weight }] }。后端收到后，在同一个事务里插入主表记录和明细表记录，并用唯一索引兜底防止重复提交。

5.4 用 ECharts 让"量化"可视化

绩效量化系统如果没有图表，说服力直接少一半。我的建议是在"统计报表"模块做三个核心图表：

• 部门平均分趋势折线图：横轴是考核周期，纵轴是平均分，一条线一个部门，直观看出涨跌。
• 个人得分雷达图：一个定制的维度打分雷达（业绩、能力、态度、协作），点击员工姓名就能看到。
• 部门等级分布饼图 / 柱状图：统计本期各部门 S/A/B/C/D 档位人数，这个在做"强制分布"分析时尤其漂亮。

ECharts 在 Vue 3 里的用法不复杂：npm install echarts，然后封装一个通用的 Chart 组件，接收 option 作为 props，组件里负责初始化实例、设置 resize 监听、销毁时 dispose。这里有一个关键配置：chart.setOption(option, { notMerge: true })，否则切换数据时图表会保留上一次渲染的状态，看起来像是多套数据叠在一起。

6. 绩效量化评分规则：怎么设计一套说得清、算得对、查得明的算法模型

6.1 评分维度与权重配置：默认方案要能给老师解释

打分最怕主观。让人直接填一个"总分"，评分人很容易随便打，领导也看不出问题。量化系统要做的是把这个"主观分"拆成多个可观测的维度。我使用的默认方案是四维评分：

• 工作业绩：权重 60%，指标如任务完成率、项目交付质量、关键节点达成数。
• 工作能力：权重 20%，指标如专业技能、问题解决能力、学习能力。
• 工作态度：权重 10%，指标如出勤率、责任心、主动性。
• 团队协作：权重 10%，指标如配合度、知识共享、跨部门协同效果。

指标表里的每个指标都独立维护，且默认权重可以配置修改。每次考核开始录入分数时，后端要把"当前的指标 + 权重"复制到评分明细表，作为本次评分快照。这样即便下个周期管理员调整了权重，历史周期的综合分也不受任何影响。这是绩效系统里最容易被忽视、但业务意义上最重要的设计。

6.2 总分计算、评级与强制分布

综合得分就是加权平均：总分 = Σ(指标得分 × 指标权重)，再除以权重总和（如果权重总和不等于 100）。有些系统会把每个指标设计成百分制再由权重加权，也有的设计成 1 到 5 档再换算百分制。我建议统一用百分制，这样每个指标的说明容易写，"该项满分 100 分，合格线 60 分"。

评级标准直接映射：

进阶加分项是"强制分布法"。现实企业里，如果一个主管给所有人全打 95 分，绩效系统就失去意义了。所以很多公司会强制规定部门的评级比例：S 级不超过 10%、D 级不低于 5% 之类的。系统里可以在报表模块做"部门评级分布预警"，当某个部门的 S 级比例超过 10% 时，页面给出提示。这个功能虽然只是提示，不影响数据，但答辩时讲 "为什么这样设计" 会让老师立刻意识到你了解企业真实管理诉求，而不是只会背书本。

6.3 一致性与防作弊：保存评分的并发处理

评分提交时，最怕的就是两个人同时对同一个员工打分，或者主管快速点了多次提交。处理方案分两层。数据库层，assess_score 表的 (period_id, user_id) 唯一索引就是兜底方案，重复插入第二笔直接报错；应用层，开启事务管理，先尝试插入主表，如果捕获到 DuplicateKeyException 就转成友好的业务提示"该员工已评分，请勿重复提交"。

还有一个容易遗漏的细节：打分时间要控制在考核周期的时间窗口内。系统里每次提交时校验 period.status 是否为"进行中"。因为评分人可能是主管，如果管理员误操作关停了周期，主管便不能提交，这个限制是完全合理的。全部用同一个周期状态开关去做，比前端禁用按钮更可靠，因为接口是能被绕过直接调用的。

7. 从零到一跑通全流程：部署细节与答辩高频问题

7.1 本地环境搭建与常见报错

环境这块我踩过的坑最多，列几个重点提醒：

本地建议统一用 JDK 1.8 或 11（SpringBoot 2.7 完美兼容）、Maven 3.8+、Node.js 16+、MySQL 8.0。数据库客户端用 DBeaver 或者 MySQL Workbench，别纠结。新建数据库时，字符集选 utf8mb4，排序规则选 utf8mb4_general_ci，不然后端往库里插中文会变成问号。

几个出现频率很高的报错：

第一，SpringBoot 启动报 Port 8080 was already in use。这不是代码问题，换个端口或者在 IDEA 里加 --server.port=8081 参数即可。

第二，Vite 开发环境跨域。在 vite.config.js 里配置 proxy，把 /api 前缀的请求代理到 http://localhost:8080，同时可以配合 rewrite 去掉路径前缀。这样开发期几乎感觉不到跨域存在。

第三，数据库连接不上。十次有八次是 useSSL 和 serverTimezone 的问题。在 application.yml 里附带加参数：

yaml复制spring:
  datasource:
    url: jdbc:mysql://localhost:3306/performance_db?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai

时区必须指定 Asia/Shanghai，不然数据库存的时间和北京时间差 8 小时，接口返回到前端后，页面上所有时间看起来都"慢了"。

7.2 打包部署：两种都能拿得出手的方式

部署是很多毕设同学临场最慌的环节。我建议准备两套方案：

方案 A（演示优先、最省事）：先把前端 npm run build 产出 dist 目录，把 dist 下所有文件拷贝到后端项目的 src/main/resources/static 目录，然后重新打包 SpringBoot jar。以后直接 java -jar 就能启动整个系统，浏览器访问 http://localhost:8080 即可。这种方式不依赖 Nginx，在设备差的环境也能飞快跑起来。

方案 B（贴近企业、讲得出东西）：前端 dist 部署到一个 Nginx 上，配置好静态文件路径和 /api 反向代理到后端 8080；后端 jar 单独用一个端口运行，二者通过 Nginx 同域打通。这种方案一般面试官提问"你懂不懂部署流程"，你能清晰说出静态资源分离、反向代理、进程隔离这些点，印象分会涨很多。

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

列出我认为最容易被问到、同时最应该提前准备的问题：

回答这些问题的核心原则是：不要背概念，要结合你自己的表和代码去说。比如问"怎么控制重复评分"，你直接说"我在 assess_score 表对周期和员工建了唯一索引，同时评分提交逻辑放在一个事务里，数据库层面和应用层面双重控制"，这会比空谈"用了锁"更有说服力。

7.4 答辩演示时最有说服力的操作顺序

最后分享一下答辩演示的操作顺序，这个顺序我实际带过好几轮学生，效果很稳：

先展示系统主页仪表盘，让老师看到整体数据概览。接着进入评分模块，以部门主管身份打开评分页面，现场提交一条评分数据，然后切到报表模块，让刚才提交的数据立刻反映在趋势图和等级分布上。再点击进去看评分明细，展示历史得分快照。这套流程演示下来，老师看到的是"一个完整业务闭环在一分钟内跑通"，远比挨个页面点一遍更让有说服力。

如果你希望在毕设之外把它做成一个可以持续扩展的项目，建议下一步往这几个方向走：引入 Redis 做验证码和热点数据缓存；加入部门主管跨部门互评机制；把考核结果和奖金计算挂钩，生成工资变动记录。但前提是先把这套核心骨架做扎实。

我自己的体会是，这套系统最难的不是写代码，而是把业务故事讲圆。很多同学代码都能跑，但讲不清为什么这么设计，一到答辩就露怯。所以哪怕你现在已经在写代码，也建议回头把数据库表关系、评分计算链路、权限拦截流程这三块重新梳理一遍，用自己的话能讲清楚，这套项目才真正属于你。

最后再补一个小技巧。无论你用 Vue 2 还是 Vue 3，前端项目里都建议保留一份 README，记录 Node 版本、启动命令、后端接口地址、访问账号。别小看这几行字，课程设计提交和毕设现场演示的时候，它能帮你省去大量临时回忆的时间。毕竟，真正把项目稳稳跑起来的，永远是那些准备到每一个细节的人。

祝顺利。