每年一到职称评审季，人事部门就像打仗一样，纸质材料堆成山、专家评审靠传递、进度追踪靠微信，光收集、整理、分发申报材料就得折腾大半个月。我做过的这个基于SpringBoot的职称评审管理系统，就是为了把整个申报到评审的流程搬上线：申报人在线填报、单位初审、专家分组评审、结果公示全程留痕，既能减少人事处的工作量，也能让申报人随时看到进度，不用一遍遍打电话问。
如果你正准备做类似的系统，或者毕业设计、项目练手正好选了这个方向，这篇内容会比较适合你。我会把从技术选型到核心功能落地、再到部署避坑的完整思路捋一遍，尤其会讲讲那些文档里不会写、但实际开发一定会遇到的细节。
1. 项目整体设计与技术选型思路
1.1 为什么选择SpringBoot作为基础框架
选题阶段很多人纠结要不要用Spring Cloud或者更重的框架，我的判断很简单：职称评审管理系统本质上是一个典型的单体业务系统，用户量在几百到几千这个级别，核心诉求是业务流程清晰、开发效率高、后期好维护，而非大规模分布式扩展。SpringBoot正好卡在这个需求点上。
SpringBoot最实在的三个价值：第一，自动配置解决了传统Spring项目里大量的XML配置，一个注解就能启动Web容器；第二，生态足够成熟，无论是连接数据库、做权限控制还是文件上传，都有现成的Starter可以引入；第三，项目结构统一，新成员接手成本低，后期不管交给谁维护都不会太痛苦。对比一下如果上Spring Cloud那套，服务注册、配置中心、网关这些组件对一个评审系统来说纯属过度设计，反而徒增运维负担。
另外一个隐藏的好处是，SpringBoot的版本选型面很宽，从2.x到3.x都有。做这个系统我建议锁定SpringBoot 2.7.x，原因后面部署部分会说，这里先提一句：2.7.x是2.x系列的最后一个稳定版本，兼容SpringSecurity 5、MyBatis-Plus等主流组件，不会再有不必要的API变更，对长期维护是最省心的选择。
1.2 系统核心角色与模块拆解
职称评审系统最怕做成一锅粥，所有功能堆在一起，谁都看不明自。我一开始就和需求方把用户角色理清了，一共五类：申报人、单位审核员、人事处管理员、评审专家、系统管理员。角色分清楚了，菜单和权限才分得清楚。
模块划分我也是按角色视角来拆的：
- 申报管理：申报人提交基本信息、学历资历、科研成果、获奖情况等材料，可暂存、可正式提交，提交后不可自行修改。
- 审核管理：单位审核员对申报材料做初审，人事处做复审，逐级把关，每次审核都留意见和记录。
- 专家评审管理：人事处发起评审批次，系统自动或手动分组，专家在线查看材料、打分、填写评审意见，支持一键评分汇总。
- 公示管理：评审结束后生成公示名单，在系统内发布公示，公示期内可发起异议申诉。
- 系统管理：用户管理、角色管理、菜单权限、操作日志、数据字典等通用功能。
这里有一点要特别强调：模块划分不只是功能的罗列，更关键的是每个模块之间的数据流转方式。比如申报人提交了材料之后，审核模块才能看到；审核通过之后，才进入专家评审池。如果你的表结构设计没有提前考虑状态流转，做到后面一定会出现数据串流程的悲剧。
1.3 技术选型中的关键权衡
这一节我把实际项目中对比过的技术方案列出来，每个都是我亲自踩过或者评估过的，希望能帮你省掉调研时间。
权限控制框架，我主要对比了Shiro和Spring Security。Shiro上手确实快，API也简单，但考虑到SpringBoot+Spring Security的整合度更高、社区资料多、对JWT的支持方案成熟，最终选了Spring Security。说实话Spring Security的学习曲线比Shiro陡，但只要你理解了过滤器链机制，后面做token校验、接口放行、角色鉴权会非常顺手。
文件存储这块，最初方案是直接存本地磁盘，后来考虑到申报材料里有很多扫描件、PDF、图片，后续可能要做在线预览和归档，改成了MinIO对象存储。MinIO的部署成本很低，单机版就是一个可执行文件，API兼容Amazon S3，配合SpringBoot的minio-io客户端也就几十行代码的事。如果只是做毕业设计，不想额外部署服务，存本地+Nginx反向代理访问也完全够用，这个可以根据场景灵活取舍。
流程控制我见过不少项目直接用Flowable工作流引擎，但对于这种固定模式的评审流程，我反而觉得自研状态机更可控。原因很简单：评审流程的阶段是固定的（申报→初审→复审→专家评审→公示→备案），没有复杂的会签或驳回再驳回的嵌套逻辑，用一个状态字段加一组状态流转方法就能搞定，出了问题也容易排查。引入Flowable等于给自己找了一个需要专门学习配置的学习成本，性价比不高。
1.4 为什么前端选Vue实现前后端分离
职称评审系统使用频率不算特别高，但使用场景分散——有人用电脑、有人用平板、甚至有人用手机提交材料。这就决定了传统模板引擎渲染的方案并不合适。我采用的是Vue3 + Element Plus + Axios的前后端分离架构，由SpringBoot提供纯JSON接口，前端独立构建部署到Nginx。
前后端分离最大的好处从开发阶段就能感受到：前后端可以并行，后端只需要把接口文档约定好，前端就能自己mock数据开发。另一个好处是部署灵活，后端打一个jar包，前端构建成静态文件，两者分别放到不同的位置，后期后端升级API时前端完全不受影响。
接口对接时遇到的JWT认证问题是这类架构的经典话题。我的做法是：用户登录成功后在Token中包含用户ID和角色信息，前端每次请求把Token放进请求头，后端通过拦截器统一校验并解析出当前用户上下文。这里要提一个坑：Token过期时间不能太长也不能太短。我一开始设置了24小时，结果发现有的专家评审到一半Token过期，提交评分时直接弹回登录页，体验非常差。后来改成7天，并实现了刷新机制，问题就解决了。
2. 核心功能模块的详细设计
2.1 申报流程的状态机设计
申报流程是整个系统的心脏，状态机设计得好不好，直接决定了后续所有功能写起来顺不顺手。我一开始就是没仔细思考，直接在代码里写if else判断状态，结果每个接口都要处理一堆边界情况，后来重构时换成了统一的状态流转设计。
我定义的状态序列是这样的：
| 状态 | 含义 | 可执行操作 |
|---|---|---|
| DRAFT | 草稿 | 编辑、提交 |
| SUBMITTED | 已提交待初审 | 审核通过/退回 |
| FIRST_AUDITED | 初审通过待复审 | 复审通过/退回 |
| FINAL_AUDITED | 复审通过待专家评审 | 分配专家/进入评审池 |
| REVIEWING | 评审中 | 专家评分/终止评审 |
| REVIEWED | 评审完成待公示 | 生成公示名单 |
| PUBLICIZING | 公示中 | 公示到期/触发申诉 |
| COMPLETED | 已完成备案 | 归档查看 |
这个状态的转换关系不是随意的，每个动作必须校验当前状态是否合法，否则就抛业务异常。实现上我采用了一个简单的状态机工具类，用Map维护每个状态允许的目标状态集合，代码非常直观：
public class ReviewStateMachine { private static final Map<String, List<String>> TRANSITIONS = new HashMap<>(); static { TRANSITIONS.put("DRAFT", Arrays.asList("SUBMITTED")); TRANSITIONS.put("SUBMITTED", Arrays.asList("FIRST_AUDITED", "RETURNED")); TRANSITIONS.put("FIRST_AUDITED", Arrays.asList("FINAL_AUDITED", "RETURNED")); TRANSITIONS.put("FINAL_AUDITED", Arrays.asList("REVIEWING")); TRANSITIONS.put("REVIEWING", Arrays.asList("REVIEWED", "TERMINATED")); TRANSITIONS.put("REVIEWED", Arrays.asList("PUBLICIZING")); TRANSITIONS.put("PUBLICIZING", Arrays.asList("COMPLETED")); } public static boolean canGo(String current, String target) { return TRANSITIONS.containsKey(current) && TRANSITIONS.get(current).contains(target); } }这种做法的好处是状态流转的逻辑集中在一个地方，加新的审核环节时只需要改动一处，而且可以很方便地统计当前所有申报单所处阶段的分布情况。真正上线后，人事处最常用的功能就是看“目前有多少人在初审、多少人到了专家评审环节”，这个统计就是基于状态字段的分组查询，SQL写起来非常直接。
2.2 数据库表设计的关键细节
表设计上我踩过一个比较大的坑，就是一开始把申报信息搞成了一张大宽表，所有字段都塞在申报主表里。结果到了开发后期，不同职称系列的申报参数不一样，有人报教授、有人报副教授、还有人报讲师，需要的字段差异很大，大宽表要么字段冗余、要么不够用。
最终采用的主表加分表方案是这样设计的：
- biz_apply_record：申报主表，存申报人ID、申报年度、申报系列（如教授/副教授）、申报职称、当前状态、申报时间等公共字段。
- biz_apply_basic_info：基本信息表，存身份证号、政治面貌、参加工作时间等通用信息。
- biz_apply_academic：学术信息表，存学历、学位、毕业院校、发表论文列表。
- biz_apply_project：科研项目表，存项目名称、级别、本人角色、经费额度等。
- biz_apply_attachment：申报材料附件表，存文件路径、文件类型、上传人、上传时间。
为什么主流做法都把扩展信息拆分出来而不是一股脑放主表？核心原因是避免数据库表结构变更。如果后面要增加一个字段，只需要新增一张子表或者在扩展表中加一行数据，而不需要ALTER TABLE结构，线上维护会安全很多。
另外，数据的逻辑删除字段DELETED、创建时间CREATE_TIME、更新时间UPDATE_TIME这三件套一定不能省。逻辑删除的作用是防止误删导致的不可恢复，这是所有业务系统都要处理的底线问题。我在项目中采用MyBatis-Plus的逻辑删除注解，配置非常简单：
@Data public class ApplyRecord { @TableId(type = IdType.ASSIGN_ID) private Long id; private Long userId; private String applyYear; private String applyCategory; private String applyTitle; private String status; @TableLogic private Integer deleted; @TableField(fill = FieldFill.INSERT) private LocalDateTime createTime; @TableField(fill = FieldFill.INSERT_UPDATE) private LocalDateTime updateTime; }2.3 材料上传与附件管理
职称评审的附件类型非常多样：学历证书扫描件、职称证书、论文PDF、获奖证明图片、继续教育证明等等，每个字段可能对应一个或多个文件。一开始我把路径字符串直接存在业务表的字段里，后来发现查询某个申报人的所有材料时非常别扭，而且没法做统一的文件大小、类型检查。
后来统一改为附件独立表维护，所有上传的文件都走同一个接口，附件表里的biz_id字段关联对应的业务记录ID，file_type字段标记是学历证书还是论文材料。这个方案的关键优势是：逻辑统一，同一个上传组件可以复用到所有模块；统计容易，按biz_id分组可以随时查出一个申报人交了哪些材料、还缺哪些材料。
文件上传这块有几个实用的校验建议：
- 单文件大小限制：建议10MB以内，超过直接拒绝，避免超大PDF拖垮服务器。
- 文件类型白名单：按扩展名和Content-Type双重校验，防止上传脚本文件。我遇到过有人修改扩展名绕过类型校验，所以不能只信扩展名。
- 文件名重命名：上传到服务器后统一用UUID作为文件名，原始文件名入库保存。这么做是为了防止中文文件名在跨平台时乱码，也防止特殊字符引发安全问题。
- 目录按日期分桶：一天的附件放一个目录，比如
2026/05/17/uuid.pdf，这样清理过期文件或做定期备份都方便。
2.4 专家评审分组的实现思路
专家评审环节最容易出问题的是公平性。设计的时候我参考了现实中评审的常用做法：每个申报人的材料随机分配3位专家独立评审，最终得分为去掉最高分和最低分后的平均值（也就是数学上说的截尾均值），这样能有效避免个别专家打分偏高或偏低带来的影响。
随机分配算法我在系统里是这么实现的：先把专家按职称系列进行分类筛选，再使用Fisher-Yates洗牌算法对申报人列表进行随机排列，然后按轮次依次分配。核心逻辑不复杂，但有一个必须处理的约束——同一个申报人不能被同一个专家评审两次，也不能分配给与该申报人有明显利益关系的专家（比如同一个单位）。这个在SQL查询阶段就把冲突数据过滤掉了，避免评审公平性受到质疑。
评分方案设计成可配置的热部署方式：每种职称系列可以单独设置评分维度（如学术水平、教学成果、社会贡献）和权重，专家填分后系统自动按权重汇总。我第一次做的时候把评分维度写死在代码里，结果人事处要在评审时临时加一个维度，只能重新发版，这点值得提前避免。
3. 核心功能代码实现与操作过程
3.1 项目初始化与基础配置
创建项目时我直接用了Spring Initializr，选择Java 8版本。这里要特别说一下JDK版本的问题：SpringBoot 2.7.x支持Java 8到Java 21，但如果你的运行环境是Java 8，一定不要直接选SpringBoot 3.x，因为3.x是基于Java 17的，会直接报ClassVersionError。这个坑很多人第一次遇到时会莫名其妙，其实本质上就是版本不兼容。
基础依赖我在pom.xml中引入了以下关键内容：
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-security</artifactId> </dependency> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.3.1</version> </dependency> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> </dependency>application.yml里核心配置就是数据源和MyBatis-Plus。这里我为什么用MySQL而不是Oracle？因为评审系统的数据量并不大，MySQL完全够用，而且配套的资料、导出工具、可视化工具都比Oracle友好。如果你在事业单位或高校里用，可能对Oracle有历史依赖，那就根据实际情况调整，SpringBoot连接Oracle只需换驱动和方言配置即可。
配置文件中有一个调试利器值得说：MyBatis-Plus的SQL日志输出。开发阶段一定要打开日志配置，这样能直接在控制台看到每次请求执行的SQL语句和参数，排查问题快得多。正式发布前再关闭，这属于基本的开发常识，但确实经常有人忘记。
3.2 JWT认证与Spring Security配置
系统采用JWT做无状态认证。用户登录成功后，后端生成Token返回，Token中包含了用户ID、用户名、角色等基本信息。之后前端每次请求在Authorization请求头中带上Bearer token，后端通过过滤器解析。
Spring Security的配置核心是重写SecurityFilterChain：
@Configuration @EnableWebSecurity public class SecurityConfig { @Bean public SecurityFilterChain filterChain(HttpSecurity http) throws Exception { http.csrf().disable() .cors().and() .authorizeHttpRequests() .antMatchers("/api/auth/login", "/api/auth/register").permitAll() .antMatchers("/api/apply/**").hasAnyRole("USER", "AUDITOR", "ADMIN", "EXPERT") .antMatchers("/api/review/**").hasRole("EXPERT") .anyRequest().authenticated() .and() .addFilterBefore(jwtAuthenticationFilter(), UsernamePasswordAuthenticationFilter.class); return http.build(); } }这里需要特别提醒的是自定义JWT过滤器必须注册在UsernamePasswordAuthenticationFilter之前，而且是addFilterBefore，很多人写错位置导致过滤器不生效。另外CORS配置在前后端分离环境下一定不能漏，否则前端无论怎么调都会有跨域报错，而且配了这一处之后就不需要在controller上再加@CrossOrigin了，否则反而会因为顺序问题产生重复请求头。
角色权限上我这里用的是基于角色的URL权限控制。比如专家评审相关的接口，必须要有EXPERT角色才允许调用。但在Controller内部还要做一层数据权限校验，防止专家去评不属于自己的申报单。比如评审接口拿到reviewId后，要根据当前登录用户ID去查这条评审记录的expert_id字段是否匹配，不匹配就拒绝访问。前后端都校验，才能保证安全底线。
3.3 申报列表的分页查询与动态条件筛选
申报列表是整个管理端用得最多的页面，直接决定了人事处日常操作的效率。我一开始用MyBatis-Plus自带的分页查询，但很快发现条件组合太多，写起来很啰嗦。后来改用MyBatis-Plus的条件构造器动态拼接，代码简洁很多：
@RequestMapping("/api/apply/list") public Result<IPage<ApplyRecordVO>> queryList(@RequestBody ApplyQueryDTO dto) { LambdaQueryWrapper<ApplyRecord> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(StringUtils.hasText(dto.getApplyYear()), ApplyRecord::getApplyYear, dto.getApplyYear()) .eq(StringUtils.hasText(dto.getStatus()), ApplyRecord::getStatus, dto.getStatus()) .like(StringUtils.hasText(dto.getApplicantName()), ApplyRecord::getApplicantName, dto.getApplicantName()) .orderByDesc(ApplyRecord::getCreateTime); IPage<ApplyRecord> page = applyRecordMapper.selectPage( new Page<>(dto.getPageNum(), dto.getPageSize()), wrapper); // 组装VO返回 }分页查询中有一个性能隐患必须注意：如果列表页需要展示申报人的附件数量、材料完整度等聚合字段，最忌讳的写法是在循环里逐条查数据库，也就是N+1问题。正确的做法是查出当前页ID列表后，用IN查询一次性把附件表的数据查出来，然后在内存里分组组装。数据量不大时这个差异不明显，但当申报人达到几百时，N+1查询会导致接口响应几秒钟都出不来。
3.4 文件上传接口的实现与测试
文件上传接口用了MultipartFile接收，配合MinIO存储。实现代码如下：
@PostMapping("/api/upload") public Result<UploadVO> upload(@RequestParam("file") MultipartFile file, @RequestParam("bizType") String bizType) { // 1. 文件类型校验 String originalFilename = file.getOriginalFilename(); String ext = originalFilename.substring(originalFilename.lastIndexOf(".") + 1).toLowerCase(); List<String> allowedExts = Arrays.asList("pdf", "jpg", "jpeg", "png", "doc", "docx"); if (!allowedExts.contains(ext)) { throw new BusinessException("不支持的文件类型"); } // 2. 大小校验 if (file.getSize() > 10 * 1024 * 1024) { throw new BusinessException("文件大小不能超过10MB"); } // 3. 存储 String datePath = LocalDate.now().format(DateTimeFormatter.ofPattern("yyyy/MM/dd")); String fileKey = datePath + "/" + UUID.randomUUID().toString().replaceAll("-", "") + "." + ext; minioClient.putObject(PutObjectArgs.builder() .bucket("review-bucket") .object(fileKey) .stream(file.getInputStream(), file.getSize(), -1) .contentType(file.getContentType()) .build()); // 4. 保存记录 // ... }这中间我踩过的比较典型的坑，就是MinIO客户端版本和对象大小参数不匹配导致的上传失败。老版本API不要求传大小，新版本必须要用stream方法并指定大小，不然一直报com.j256.simplemagic.ContentTypeUtilException之类的迷惑错误。如果你用Docker桌面版的MinIO，还要注意地址不能填localhost，因为容器内的localhost指向的是容器自己，我遇到这个问题后在外部浏览器能访问、程序里却连不上，排查了半天才发现是网络模式的问题。
上传不是难点，下载和在线预览才是。对于PDF在线预览，最简单的做法是给一个直接访问的文件URL，浏览器自动渲染；对于图片类，直接放img标签就能预览；对于Office文档，如果不想自己装在线预览服务，可以借助WPS开放平台这类第三方转换服务，把文档转成PDF再预览。这块视你的部署环境和预算而定，不是系统核心，可以先做到下载+PDF预览就够了。
3.5 专家评审评分的核心算法实现
刚才提到专家评审采用去掉最高分和最低分的截尾平均法。这个算法本身很简单，但真正的复杂度在于：系统需要保证每位专家的评分表能独立提交、互不可见，直到该申报人的所有专家都完成评分后，才能计算出最终得分。
实现上我设计了两张表：评审组表review_group和评审记录表review_result。前者是一次评审批次的分组信息，后者是每位专家对某个申报人的评分明细。核心计算逻辑如下：
public BigDecimal calculateFinalScore(Long applyId) { List<ReviewResult> results = reviewResultMapper.selectList( new LambdaQueryWrapper<ReviewResult>() .eq(ReviewResult::getApplyId, applyId) .eq(ReviewResult::getStatus, "COMPLETED")); if (results.size() < 3) { throw new BusinessException("该申报人有效评审人数不足3人，无法计算成绩"); } List<BigDecimal> scores = results.stream() .map(ReviewResult::getTotalScore) .sorted() .collect(Collectors.toList()); // 去掉最高分和最低分 scores.remove(0); scores.remove(scores.size() - 1); // 平均分保留两位小数 BigDecimal sum = scores.stream().reduce(BigDecimal.ZERO, BigDecimal::add); BigDecimal avg = sum.divide(BigDecimal.valueOf(scores.size()), 2, RoundingMode.HALF_UP); return avg; }这个实现里有一个细节：当评审人数只有3人时，去掉最高最低后只剩一个分数，也就是中间分，这种做法在现实中是合理的，能避免个别专家一人独大。但如果评审人数是5人，去掉两个后取3人的均值，结果就更有代表性。在需求阶段要跟人事处确认清楚评审专家数量，再决定算法细节，不要自己闷头假设。
3.6 公示与备案功能的数据流转
评审完成之后进入公示环节。公示状态下的数据要支持两种操作：一是所有人可查看但不可修改，二是对公示名单有异议的人在规定时间内发起申诉。系统里公示记录表的design字段控制着异议功能是否开放，由人事处角色决定。
公示到期后，人事处确认无异议，申报单流转到COMPLETED状态。这时需要把整套申报材料和评审记录归档，生成一份完整的评审档案表。这块我是用定时任务做了每日归档检查：状态为COMPLETED且档案表不存在的申报单，自动把关键信息冗余到档案表。之所以要做冗余，是因为申报人基本信息、材料表可能后续发生修改（虽然记录不会，但作为一张独立的归档表更保险），评审结果要跟原始数据做快照。
4. 系统部署与常见问题排查实录
4.1 使用Docker部署SpringBoot项目
部署环节根据实际环境选择，我这边用的是Docker加一键启动脚本的方式。先在项目根目录编写Dockerfile：
FROM openjdk:8-jdk-alpine VOLUME /tmp COPY target/review-system.jar app.jar ENV JAVA_OPTS="-Xms256m -Xmx512m" ENTRYPOINT ["sh", "-c", "java $JAVA_OPTS -Djava.security.egd=file:/dev/./urandom -jar /app.jar"]这里有个容易踩的坑是时区问题：Docker容器默认是UTC时区，如果你的业务代码用到了LocalDate.now()或者Date类，会发现数据的时间比本地时间少了8小时。必须在启动参数中加上-Duser.timezone=GMT+8，或者在Dockerfile里设置环境变量ENV TZ=Asia/Shanghai。这个坑我第一次部署时没注意，结果生成的申报日期全部错位，排查了很久才定位。
JVM参数设置上，我建议给这个系统分配256MB到512MB的堆内存就够了，因为你配合Nginx部署、MySQL、MinIO一起跑的时候，服务器总共也就2G4G的内存，千万不要贪心给太多。如果内存只有1G，可以考虑手动回收参数，或者用容器内存限制。
4.2 SpringBoot事务失效的常见场景
这个系统的报名、提交、审核等操作都牵扯到多张表的更新，事务的使用非常频繁。我遇到过两次事务不生效的问题，很典型：
第一次是在同一个类内部调用事务方法。Spring事务的底层原理是AOP代理，通过代理对象调用方法时才会触发事务拦截器，而类内部直接用this调用时调用的是原始对象，事务就失效了。解决方法是把事务方法拆到另一个Service类里，或者注入自身的代理对象。
第二次是异常被捕获导致的。我用try-catch把业务异常包住之后没有抛出，事务自然就没办法回滚。这也是事务失效非常典型的原因——事务管理器看到的是方法正常结束，自然就提交了。正确的做法是：不要吞掉异常，要么直接抛出，要么在catch中显式调用TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()。
还有一个事务相关的点：数据库表引擎必须支持事务。MySQL默认的InnoDB没问题，但如果哪张表被误建成了MyISAM，事务会静默失效，这个问题更隐蔽，查了很久才发现。建表时建议统一指定ENGINE=InnoDB。
4.3 数据库连接池配置优化
SpringBoot默认使用HikariCP连接池，这个连接池本身性能很好，但默认配置在长时间运行的系统中需要针对实际业务做调整。我的项目里加了如下配置：
spring: datasource: hikari: maximum-pool-size: 20 minimum-idle: 5 connection-timeout: 30000 idle-timeout: 600000 max-lifetime: 1800000这里有一个比较重要的经验：mysql的wait_timeout默认是8小时，如果一段时间的空闲连接被MySQL服务端主动关闭了，而连接池不知道，就会报Communications link failure错误。HikariCP的max-lifetime必须小于MySQL的wait_timeout，才能保证连接池自己回收的不是已经被服务端断掉的那个连接。
4.4 常见错误排查速查表
| 现象 | 可能原因 | 解决方案 |
|---|---|---|
| 前端请求接口报401 | Token过期或未携带 | 检查请求头是否为Authorization: Bearer xxx |
| 接口报403 | 角色权限不足 | 登录用户角色是否匹配@PreAuthorize要求 |
| 上传文件报413 | Nginx层限制 | 修改Nginx的client_max_body_size参数 |
| 时间显示差8小时 | 时区配置问题 | 容器/连接串/Jackson配置统一GMT+8 |
| 审查查询很慢 | 缺少索引 | 给申报状态、年度、用户ID加联合索引 |
| 前端跨域 | CORS配置缺失 | Spring Security中配置cors().and() |
| 专家评分无法提交 | 评审状态不属于REVIEWING | 检查状态机流转是否被错误修改 |
| 附件无法预览 | 文件类型不支持 | 检查上传时文件类型白名单及预览组件 |
排查问题时我最推荐的思路是：先看日志，再看SQL，最后看前端请求。很多新人一上来就改代码，越改越乱。如果能看到控制台SQL日志，先确认底层执行的SQL是不是自己预期的那条，往往能省掉一半的时间。SpringBoot的devtools热部署在这个项目里可以开，但要小心它与自定义启动类的兼容性，生产环境一定要关闭。
4.5 多环境配置管理与发布
职称评审系统往往要同时跑在开发、测试、生产三个环境中，每个环境的数据库地址、文件存储密钥都不同。我用的是SpringBoot多Profile方案：
spring: profiles: active: @profile.active@在pom.xml里配合profile定义各环境的属性变量，打包时通过-Pdev、-Pprod来指定。因为系统内部可能有敏感配置，比如数据库密码，我建议使用Jasypt做加密处理。Spring Boot整合Jasypt很成熟，配置一个加密key，在配置文件中用ENC(加密串)替代明文密码即可。这样即使配置文件泄露，也不会直接把数据库密码暴露出去。
发布流程上，我习惯先打测试包，在测试环境完整过一遍核心流程（申报→审核→专家评审→公示），确认无误后再打生产包。这个项目因为评审有固定年度节点，所以发布窗口要避开评审高峰期，最好在评审季之前完成全流程验证。
5. 一些踩坑后的经验总结
这个系统从设计到落地，前后花了大概两个月时间，中间遇到的问题不少，但真正核心的收获不是代码写了多少，而是对业务流程的理解。做这种业务系统，最忌讳的是只盯着技术炫技，而不去理解评审流程的本质。比如为什么初审和复审要分开？为什么专家要独立评分？这些规则背后都是几十年管理经验沉淀下来的公平性设计，系统只是把它们数字化而已。
如果你准备照着这个方向做，我有几个建议：第一，先把业务流程图和数据流转图画清楚，再开始写代码，别急着建项目；第二，数据库表设计宁可多拆几张表，也别图省事全塞在一起；第三，一定要留时间做核心流程的完整测试，尤其是状态流转的边界情况，比如退回之后能不能重新提交、评审中途能否更换专家等。
后续如果有时间，我还会往这个系统里加一个电子签章接口，让评审结果直接生成带数字签名的PDF文件，省去打印盖章的麻烦。信息化系统做到最后，往往就是替用户把这些琐碎的线下操作一点点消灭掉，这也是我做这个系统最有成就感的地方。
