企业官网建设流程全解析

1. 先聊聊这个项目解决的到底是啥问题

做教师教学培训管理系统之前，我在学校里转过一圈，发现一个非常典型的现状：培训通知靠微信群接龙，报名统计靠Excel来回合并，签到靠纸笔，学时台账在年底汇总时能把教务老师逼疯。不同科室各存一份表，数据口径对不上，问起来就是"我们这边明明报了三十个人"。这个项目，本质上就是把这一整条线搬到线上：培训项目统一发布、教师在线报名、管理员审批、签到记录自动累计学时、学期末一键导出统计报表。

从技术角度看，这是一套典型的Java全栈管理系统，后端以SpringBoot为骨架，前端用Vue，数据库用MySQL，整体走前后端分离模式。它解决的不仅是"有没有用"的问题，更关键的是把分散在Excel、纸质签到表、微信群里的数据统一收口，让每一场培训都能追溯：谁发布了、谁报名了、谁参训了、得了多少学时、效果评价如何。这套逻辑放到很多场景都成立，企业内部的员工培训、行业学会的继续教育、医院规培管理，换个表名和字段就能复用，属于做完一个能理解一类项目的典型选题。

适合谁看呢？第一类是想选毕业设计题目的计算机相关学生，第二类是刚接触SpringBoot、想找一个完整CRUD加报表导出练手项目的初级开发者，第三类是学校里或培训机构里真准备做信息化改造、但预算有限只能自己搭的老师。三类人的诉求不一样，但都能从这套系统的设计思路里拿到自己能用的东西。

1.1 从痛点出发：为什么需要这样一套系统

先别急着想数据库表，把业务跑一遍你才知道哪些字段不能少。我记得第一次做需求调研时，教务老师提了一句话："我就想知道这学期每个老师参加了几次培训、一共多少学时、哪个学院参加得最少。"就这一句话，直接决定了整个系统的核心：培训项目 + 报名记录 + 参训记录 + 学时汇总，四件事。

再把场景扩展一下，完整的业务链条是这样的：

1. 管理员发起培训项目：填写培训主题、类型（新教师岗前培训、教学能力提升、信息化专项、师德专题等）、主讲人、时间地点、学时数、名额上限。
2. 教师在系统里看到培训列表，选择报名。如果超过截止时间或名额满了，报名入口关闭。
3. 管理员审批报名，通过后教师按时间参训，现场扫码或签到确认。
4. 培训结束后，教师可以提交评价；管理员补录或者系统自动生成参训记录，并累加学时。
5. 学期或年度末，按学院、个人、培训类型三个维度统计：学时完成情况、覆盖率、人均参训次数，导出Excel。

这里有个容易忽视的点：学时不是报名就算的，必须以签到或审批后的参训记录为准。很多初版系统把报名记录直接当成学时依据，结果教师报了名不来，学时照样记上，业务部门一核对就出问题。所以我会在设计里把报名表（registration）和参训记录表（record）分开，报名通过只是拿到了"入场资格"，真正计学时靠的是参训记录。这套区分在后面对接统计报表时省了很大的事。

1.2 技术选型的取舍：为什么是SpringBoot + Vue

这个项目为什么选择SpringBoot而不是其他方案？我在选型时有两个核心考虑：生态和岗需。

先说生态。教师培训管理系统本质上是一个标准的信息管理系统，需要的技术栈是：Web框架、ORM、权限认证、报表导出、前端界面。SpringBoot在这条路上基本是"毕业即就业"的主流答案，自动配置省掉了大量XML配置，内嵌Tomcat让部署变成一个java -jar命令；配合MyBatis-Plus这种增强插件，单表CRUD甚至不用写SQL；Spring Security或者Sa-Token解决登录鉴权；Apache POI处理导出。这一整套方案在网上有大量成熟案例，万一踩坑，搜索一下基本都能找到答案。

再考虑数据规模和并发。一所高校的教师数量大概在一千到五千人，培训项目一个学期几十场，报名记录可能过万。这个量级用MySQL完全扛得住，不需要引入Redis做缓存，更不需要微服务那套注册中心、网关、配置中心的复杂架构。我见过不少毕设或小项目为追求"高大上"硬上一套Spring Cloud，结果光服务拆分和链路排查就把人折腾够呛，业务却只有三张表。技术选型不是越新越重越好，而是要匹配真实负载。这套系统里，SpringBoot单体应用 + 合理索引 + 缓存可行性评估，就已经能覆盖上线后三五年的数据增长。

前端选Vue是当前前后端分离的主流搭配，但如果你是自己一个人做，不熟悉Vue也没关系，可以直接用服务端渲染方式，SpringBoot提供Thymeleaf模板，业务上完全成立。我之前做这个项目时选了Vue + Element UI，原因只有一个：表格表单组件成熟，管理后台界面几乎不用自己造轮子。这个决定可以从第2章的数据结构继续展开。

2. 系统设计落地：数据库、接口与权限模型

这一章是最有技术含金量的部分。很多刚上手的人喜欢上来就建表，我觉得顺序应该反过来：先画出业务流转图，再根据流转表定表，最后才写字段。下面把我实际用过的表结构设计、接口约定和权限模型分别说清楚，这些都是可以直接抄作业的。

2.1 数据库表设计：我踩过的最重要的几个坑

先给一份核心表清单，五张业务表加三张基础表：

这里有几个坑值得提醒。

第一个坑：用户表千万不能只存姓名。教师培训系统里，登录用户是教师，但统计要按学院、职称、入职年份分组，所以至少要把teacher_info拆出来，和sys_user做一对一关联。如果你把姓名、学院、职称全塞进user表，后期做"按学院统计参训率"就只能在user表上加一堆业务字段，表职责混乱，维护久了必炸。实际做的时候我还在teacher_info里加了entry_date（入职时间）和teacher_no（工号），因为很多培训项目对新教师和骨干教师有不同要求，这些字段在筛选和统计时都会用到。

第二个坑：唯一索引比代码校验更可靠。防重复报名，最稳妥的是在training_registration表上加联合唯一索引(project_id, teacher_id)，同时在Service层写一遍查重逻辑。索引是兜底，代码逻辑是用户体验。并发场景下，两个人同时点击报名，代码查重可能都查到"未报名"，然后都写了insert，唯一索引会直接拒绝掉第二个请求，这样才能保证数据不重复。

ALTER TABLE training_registration ADD UNIQUE KEY uk_project_teacher (project_id, teacher_id);

第三个坑：参训记录的学时来源。培训系统里，学时数可能来自几个不同渠道：项目预设学时、管理员手动调整、补录历史数据。如果只在training_record里放一个hours字段，以后追溯时不知道这个数是谁定的。我习惯加上source字段，取值：AUTO（按项目默认学时）、ADMIN_EDIT（管理员修改）、IMPORT（历史数据导入）。后面做统计报表时如果发现某个学院学时异常，直接按source筛一遍就能定位原因。

第四个坑：状态字段用int还是varchar。我见过有人用int 0、1、2表示审批状态，代码里写注释说明，时间一长注释丢了，看到0都不知道是"待审核"还是"已拒绝"。我最后统一用varchar存状态枚举，比如PENDING、PASSED、REJECTED，虽然多占几个字节，但是代码可读性、日志排查、接口传输都友好得多。甚至可以直接把枚举类名作为常量映射，前后端约定用同一个词。

2.2 接口设计与前后端约定

接口设计上，我建议按资源划分，统一以/api开头，admin相关的路径加/admin，教师端不加。当初定义的几组核心接口如下：

POST /api/auth/login 登录，返回token GET /api/user/project/list 教师端分页查询培训项目 POST /api/user/registration 教师提交报名 GET /api/user/mine/records 教师查看自己的参训记录和累计学时 POST /api/admin/project 管理员创建培训项目 PUT /api/admin/project/{id} 编辑项目 POST /api/admin/audit/{id} 审批报名（通过/拒绝） GET /api/admin/statistics 统计报表（按学院/按时间） GET /api/admin/export 导出Excel

前后端分离模式下，接口约定比接口本身更重要。我这里说几个实际工作中的教训：

统一返回结构。无论成功失败都给前端一个固定JSON格式：

{ "code": 200, "message": "success", "data": {} }

code用200表示成功，非200表示失败；前端只需判断code。业务异常在全局异常处理器里统一捕获，转换成对应的code，不要让Spring Boot默认的错误页直接抛给前端。

分页参数统一。我用的格式是pageNum从1开始、pageSize默认10，返回给前端的是MyBatis-Plus的IPage对象：{records, total, pages, current}。前端表格组件直接绑字段，后端不用为每个列表接口单独定制返回格式。

时间格式统一。这是一个高频踩坑点。后端LocalDateTime如果直接序列化，前端拿到的是2024-05-12T09:30:00这种带T的字符串，Element UI的日期组件显示起来很别扭。我在application.yml里加统一配置：

spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8

这样所有接口的时间字段统一输出成人类可读格式，省掉前端一堆转换代码。

2.3 权限模型：别把权限写死在代码里

教师培训系统的角色其实比较简单：ADMIN和TEACHER，如果再细分，可以有教务管理员（负责培训发布的TRAINING_MANAGER）和院系管理员。我建议用经典的RBAC（基于角色的访问控制），不需要引入太复杂的安全框架，直接用拦截器或过滤器校验角色即可。

具体做法是：登录成功时后端签发JWT，token里带上用户id和角色编码；前端把token存在localStorage或pinia里。请求时放在Authorization: Bearer <token>请求头中。后端写一个JWT拦截器，统一解析token，把用户信息放入ThreadLocal或请求上下文。

public class JwtInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { // 放行登录接口和部分公开接口，在配置类里用excludePathPatterns控制 String token = request.getHeader("Authorization"); if (StringUtils.hasText(token) && token.startsWith("Bearer ")) { token = token.substring(7); Claims claims = JwtUtil.parseToken(token); if (claims != null) { request.setAttribute("userId", claims.get("userId")); request.setAttribute("role", claims.get("role")); return true; } } response.setStatus(401); return false; } }

拦截器里只校验token合法性和角色，不把具体某个接口的权限写在Controller里。因为角色只有两三种，靠注解@RequireRole("ADMIN")就能控制，但如果你预计角色会膨胀（比如要加"院系审核员"），再引入Sa-Token的权限框架或自定义@PreAuthorize注解都不迟。当前这个项目规模下，拦截器是最简洁、最不容易出错的方案。

3. 核心模块实现：报名、审批、统计这条主线

系统设计完之后，真正干活儿的部分来了。我按照业务主链路挑三个难点详细说一下：JWT认证的落地细节、并发场景下的报名与审批逻辑、以及POI导出统计表。这三个部分几乎覆盖了面试官最喜欢追问的问题，也是你把这个项目写进简历时最值得展开的点。

3.1 认证模块：JWT其实没那么玄

登录接口的核心逻辑就是"查用户、校验密码、发token"三步。

@PostMapping("/login") public Result<LoginVO> login(@RequestBody LoginDTO dto) { // 1. 校验用户名是否存在 User user = userService.lambdaQuery() .eq(User::getUsername, dto.getUsername()) .one(); if (user == null) { return Result.error("用户不存在"); } // 2. 校验密码，注意密码不能明文存，BCrypt加密 if (!BCrypt.checkpw(dto.getPassword(), user.getPassword())) { return Result.error("密码错误"); } // 3. 检查账号是否被禁用 if (user.getStatus() == 0) { return Result.error("账号已被停用，请联系管理员"); } // 4. 生成token，有效期我设的是24小时 Map<String, Object> claims = new HashMap<>(); claims.put("userId", user.getId()); claims.put("role", user.getRole()); String token = JwtUtil.generateToken(claims, 24 * 60 * 60 * 1000); return Result.ok(new LoginVO(token, user.getRole(), user.getName())); }

密码存储我统一用BCrypt而不是MD5。原因不多讲，MD5加盐虽然也能用，但BCrypt是自适应哈希，抗暴力破解能力更强，Spring Security里自带这个工具类，引入成本几乎为零。这个细节你在面试时提一嘴，会显得有安全意识。

JWT的有效期是个值得说道的细节。一天过期够用吗？如果寒暑假期间长期不用，token过期后前端要跳回登录页，体验不好。我的做法是：token有效期7天，但里面存一个lastActive时间，拦截器每次解析token时检查，如果超过一天没活跃就返回一个特殊错误码code: 40101，前端收到后自动跳登录。这么做比设置极短有效期"强制用户频繁登录"体验好，也比不做任何处理更安全。

3.2 报名与审批：唯一索引和状态机的配合

报名接口看起来简单，就是往registration表插一条记录，但加上业务约束后就没那么随意了。我梳理出的约束条件有四个：

1. 项目必须处于OPEN报名中状态；
2. 当前时间必须在报名起止时间之间；
3. 该教师没有被审批拒绝过且没有已参加的记录；
4. 如果设置了名额上限，已通过人数不能超过limit_count。

前三个条件在Service里逐条校验，第四个条件要小心处理。如果直接查count再判断是否小于limit，并发下会出现超额：100个名额，第101和102个人同时查到100，然后都写入了。我的解决方案是：报名阶段不锁名额，只保证"不重复报名"；审批阶段由管理员逐条处理，超员的项目管理员在审批时能看得到当前通过人数，手动拒绝多余报名。对于教师的教务管理员来说，这个操作习惯比系统的自动沙盒更符合实际——他们更信任自己"点一下通过/拒绝"的过程。

审批接口的本质是一个状态流转：

待审核(PENDING) -> 通过(PASSED) 待审核(PENDING) -> 拒绝(REJECTED)

管理员审批通过后，我的代码同时会在training_record里插入一条待参训记录，学时先按项目预设hours写入，但标记为NOT_SIGNED。等培训当天实际签到后，再把状态改成SIGNED，学时正式生效。这样做的原因是：报名通过但人没来的情况很常见，学时不能提前计入。签到的方式我建议用最简单的"管理员按名单勾选"，扫描二维码的方案涉及微信小程序或专用设备，明显超出这个项目的主线了，而且还要处理二维码过期、代签等各种边界，非必要不引入。

3.3 学时统计与导出：POI的正确打开方式

统计这块是系统里最直观体现价值的功能。学期末，教务老师打开页面，选择学年学期，点击导出，一份按学院汇总的Excel立刻生成。当年手工汇总要花两三天的活儿，这里只要三秒钟。

统计SQL的核心就是分组聚合：

SELECT t.college, t.title, COUNT(DISTINCT tr.teacher_id) AS trained_teacher_count, SUM(CASE WHEN tr.sign_status = 'SIGNED' THEN tr.hours ELSE 0 END) AS total_hours FROM training_record tr LEFT JOIN teacher_info t ON tr.teacher_id = t.id WHERE tr.year = #{year} AND tr.semester = #{semester} AND tr.sign_status = 'SIGNED' GROUP BY t.college, t.title

这里有个细节：分组字段和查询字段必须保持一致，trained_teacher_count是去重后的参训人数，total_hours是总学时。同一个教师参加多场培训，在记录表里有多行，统计人数时不能直接count行数。这个坑我踩过，表格里人数虚高一倍，最后排查发现是没加DISTINCT。

导出Excel我用的是Apache POI的EasyExcel方案。准确说，对于简单的数据导出，我推荐阿里巴巴的EasyExcel而不是原生POI。原因很简单：原生POI写一个带样式的Excel需要手动创建CellStyle、设置字体、调整列宽，代码量大且容易内存溢出；EasyExcel基于注解，几行代码搞定。

@Data @HeadStyle(horizontalAlign = HorizontalAlignEnum.CENTER) @ContentRowHeight(20) @HeadRowHeight(24) public class TrainingStatRow { @ExcelProperty("学院") private String college; @ExcelProperty("职称") private String title; @ExcelProperty("参训人数") private Integer trainedCount; @ExcelProperty("总学时") private BigDecimal totalHours; }

然后导出接口就变得非常清爽：

@GetMapping("/export") public void export(HttpServletResponse response) throws IOException { List<TrainingStatRow> rows = trainingRecordMapper.selectStatRows(year, semester); response.setContentType("application/vnd.openxmlformats-officedocument.spreadsheetml.sheet"); response.setCharacterEncoding("UTF-8"); String fileName = URLEncoder.encode(year + "年学期培训统计", "UTF-8"); response.setHeader("Content-Disposition", "attachment;filename*=UTF-8''" + fileName + ".xlsx"); EasyExcel.write(response.getOutputStream(), TrainingStatRow.class) .sheet("培训统计") .doWrite(rows); }

注意导出文件名的处理，这个细节能劝退一大批人：如果用response.setHeader直接设置中文文件名，容易在跨浏览器时乱码，统一用URLEncoder.encode+filename*=UTF-8''的方式最稳。

有个热词是"java poi word能生成图表吗"，这里顺便把我的经验说透。POI确实可以从Word的XWPFDocument里插入图表（Chart），但API非常有限，只能做柱状图折线图，样式调整也很受限制。真需要生成带图表的培训分析报告Word文档，我的做法是：提前用Word做一个带书签的模板，后端用POI填充文字内容，图表部分直接在模板里手工排好，需要更新数据时用契约把图表的数据源区域替换掉。比纯代码生成图表可靠得多。

4. 常见问题排查与优化实录

开发过程中踩的坑不少，这里挑几个最具代表性的问题写出来，每一个都是我真实遇到并排查过的。

4.1 开发期的高频Bug：乱码、跨域和日期序列化

中文乱码，准确说是MySQL插入中文不乱码，但查询条件带中文返回不了数据。问题几乎都出在JDBC连接串。我用的连接串是：

jdbc:mysql://localhost:3306/training_system? useUnicode=true&characterEncoding=UTF-8&serverTimezone=Asia/Shanghai

characterEncoding=UTF-8必须显式加上，只靠MySQL默认字符集有时会继承到latin1。另外创建表时尽量统一用utf8mb4，能存emoji和特殊字符，排序规则选utf8mb4_general_ci或者更严格的utf8mb4_unicode_ci。这里敲一下重点：如果表已经建好，ALTER TABLE ... CONVERT TO CHARACTER SET utf8mb4;可以改，但已有数据的表转换时要小心，最好先在测试库试。

跨域问题，前后端分离项目的标配坑。开发时前端跑在localhost:5173，后端跑在8080，如果不配置跨域，浏览器直接拦截。

@Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/api/**") .allowedOriginPatterns("*") .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS") .allowedHeaders("*") .allowCredentials(true) .maxAge(3600); } }

生产环境我建议去掉allowedOriginPatterns("*")，改为Nginx代理，让前端请求走同域路径/api，Nginx把请求转发到后端服务，这样前端根本不用关心跨域，后端也更安全。

日期序列化问题前面提过，这里再补一个：如果返回的是Date而不是LocalDateTime，time-zone: GMT+8配置不一定生效，需要检查Jackson的使用类型。我后来统一用LocalDateTime，配合@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss", timezone = "GMT+8")注解兜底，不管全局配置怎么变，字段级注解最强。

4.2 性能与并发：数据量起来以后怎么办

教师培训系统理论上并发不会太高，全校同时登录的峰值一般在开学初培训通知发布后的一两个小时。但既然你把这个项目写进简历，最好能说出点性能优化的思路，免得面试官觉得你只会CRUD。

我的优化思路按优先级排：

1. 索引优化。报名表建立在project_id、teacher_id上的联合索引是必须的；参训记录表year + semester建立索引，统计查询从全表扫描变成索引范围扫描。用EXPLAIN看执行计划时，如果出现了Using filesort或Using temporary，多半是索引没设计好，调整group by或order by字段的索引组合就行。

2. 分页查询的深翻页问题。列表页如果用户翻到第100页，MyBatis-Plus底层是LIMIT 990, 10，数据量大时会越来越慢。优化方式有两个：一是前端限制只能查询前100页，二是用延迟关联方式分页，先只查主键再回表取详细数据。

// 延迟关联示例 SELECT r.* FROM training_record r INNER JOIN ( SELECT id FROM training_record WHERE year = #{year} ORDER BY create_time DESC LIMIT #{offset}, #{pageSize} ) tmp ON r.id = tmp.id

3. 缓存。培训项目列表这种读多写少的数据，在项目发布后短时间内会被大量刷新，我加了Spring Cache的@Cacheable注解，缓存5分钟，有效降低数据库压力。教师个人信息则用@CachePut在更新时刷新缓存。这个量级没必要上Redis，Caffeine本地缓存足够，注意集群部署时本地缓存不能共享，但目前这套系统单节点部署，完全没问题。

4.3 部署上线：从Jar包到Docker

部署方案我给过两套：传统方案和容器方案。传统方案最简单，服务器装JDK，把项目打成Jar包：

mvn clean package -DskipTests nohup java -jar training-system.jar --spring.profiles.active=prod > log.out 2>&1 &

nohup加>重定向，把日志输出到文件。生产环境一定要指定profile，区分开发库和生产库，我在这上面吃过亏，差点把测试数据清掉。

容器方案用Docker-compose一起编排后端、前端和MySQL，这是当前中小项目的主流方式。Dockerfile就几行：

FROM openjdk:17-jdk-slim WORKDIR /app COPY target/training-system.jar app.jar EXPOSE 8080 ENTRYPOINT ["java", "-Xms256m", "-Xmx512m", "-jar", "app.jar"]

这里特别注意内存参数。云服务器如果只有2G内存，JVM默认堆大小可能占掉服务器一大半，加上MySQL，直接内存耗尽。我建议JVM堆设256m起步、512m封顶，配合-XX:+UseG1GC。.env文件里再定义MySQL密码、数据库名等环境变量，docker-compose起来以后，整个系统一条命令搞定。

Nginx做前端静态资源托管和反向代理时，关键配置就一段：

server { listen 80; server_name training.example.com; location / { root /usr/share/nginx/html; index index.html; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://backend:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }

try_files这行是Vue前端history路由的核心，刷新页面时如果Nginx找不到对应路径就会返回到index.html，交给前端路由处理。

5. 最后分享点实在的经验

如果你正在准备做类似的系统，我个人有几点体会供参考。

第一，先跑通主链路再补细节。我的开发顺序是登录 -> 项目发布 -> 报名 -> 审批 -> 参训记录 -> 统计导出，六步走通以后，系统已经能交付给教务使用。之后再慢慢加评价、消息通知、教师档案导入这些功能。千万别一上来就抠UI，管理后台的业务人员对界面要求远低于对流程闭环的要求。

第二，数据字典能救你后半程的命。培训类型、审批状态、报名状态这些字段，在一个系统里会有多个模块使用。我用了一张sys_dict表存所有字典项，前端通过接口拉取下拉选项，后端也可以统一从DictUtil工具类读取。这样改动字典数据不需要发版，比在代码里写死枚举更灵活。如果不想建字典表，那至少要把枚举常量单独放在一个类或enum里，千万不能散落在各处魔法字符串。

第三，不要忽略日志。刚开始我图省事，Service里只在异常时打日志，结果有一次管理员说"我明明审核通过了，为什么教师看不到"，后台一查log，发现教师端列表接口的SQL有个条件过滤了状态，根本没查出来。后来我在所有关键操作（创建项目、报名、审批、导出）里都加了一条info日志，记录操作人、操作时间和业务主键。排查问题从"猜"变成"看日志定位"，效率高了一个数量级。

这个系统做完以后，整个培训管理的流程肉眼可见地顺了很多。对我个人而言，最大的收获不是代码量，而是明白了一个道理：大部分业务系统到最后拼的不是框架多新，而是对业务细节的理解和数据流的梳理。这套设计思路迁移到企业培训、课程报名、甚至会议管理都能用。你要做的，就是拿这个项目把SpringBoot的常用开发模式练熟，把"从需求到上线"整套流程跑通，面试时能讲清楚每个设计为什么这么做，就已经赢过一大半同类项目了。