每年一到职称评审季人事部门就像打仗一样纸质材料堆成山、专家评审靠传递、进度追踪靠微信光收集、整理、分发申报材料就得折腾大半个月。我做过的这个基于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也简单但考虑到SpringBootSpring 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 MapString, ListString 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字段关联对应的业务记录IDfile_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 groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-security/artifactId /dependency dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3.1/version /dependency dependency groupIdorg.projectlombok/groupId artifactIdlombok/artifactId /dependencyapplication.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的配置核心是重写SecurityFilterChainConfiguration 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 ResultIPageApplyRecordVO queryList(RequestBody ApplyQueryDTO dto) { LambdaQueryWrapperApplyRecord 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); IPageApplyRecord page applyRecordMapper.selectPage( new Page(dto.getPageNum(), dto.getPageSize()), wrapper); // 组装VO返回 }分页查询中有一个性能隐患必须注意如果列表页需要展示申报人的附件数量、材料完整度等聚合字段最忌讳的写法是在循环里逐条查数据库也就是N1问题。正确的做法是查出当前页ID列表后用IN查询一次性把附件表的数据查出来然后在内存里分组组装。数据量不大时这个差异不明显但当申报人达到几百时N1查询会导致接口响应几秒钟都出不来。3.4 文件上传接口的实现与测试文件上传接口用了MultipartFile接收配合MinIO存储。实现代码如下PostMapping(/api/upload) public ResultUploadVO upload(RequestParam(file) MultipartFile file, RequestParam(bizType) String bizType) { // 1. 文件类型校验 String originalFilename file.getOriginalFilename(); String ext originalFilename.substring(originalFilename.lastIndexOf(.) 1).toLowerCase(); ListString 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) { ListReviewResult results reviewResultMapper.selectList( new LambdaQueryWrapperReviewResult() .eq(ReviewResult::getApplyId, applyId) .eq(ReviewResult::getStatus, COMPLETED)); if (results.size() 3) { throw new BusinessException(该申报人有效评审人数不足3人无法计算成绩); } ListBigDecimal 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加一键启动脚本的方式。先在项目根目录编写DockerfileFROM 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.egdfile:/dev/./urandom -jar /app.jar]这里有个容易踩的坑是时区问题Docker容器默认是UTC时区如果你的业务代码用到了LocalDate.now()或者Date类会发现数据的时间比本地时间少了8小时。必须在启动参数中加上-Duser.timezoneGMT8或者在Dockerfile里设置环境变量ENV TZAsia/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事务会静默失效这个问题更隐蔽查了很久才发现。建表时建议统一指定ENGINEInnoDB。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 常见错误排查速查表现象可能原因解决方案前端请求接口报401Token过期或未携带检查请求头是否为Authorization: Bearer xxx接口报403角色权限不足登录用户角色是否匹配PreAuthorize要求上传文件报413Nginx层限制修改Nginx的client_max_body_size参数时间显示差8小时时区配置问题容器/连接串/Jackson配置统一GMT8审查查询很慢缺少索引给申报状态、年度、用户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文件省去打印盖章的麻烦。信息化系统做到最后往往就是替用户把这些琐碎的线下操作一点点消灭掉这也是我做这个系统最有成就感的地方。
每年一到职称评审季人事部门就像打仗一样纸质材料堆成山、专家评审靠传递、进度追踪靠微信光收集、整理、分发申报材料就得折腾大半个月。我做过的这个基于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也简单但考虑到SpringBootSpring 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 MapString, ListString 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字段关联对应的业务记录IDfile_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 groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-security/artifactId /dependency dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3.1/version /dependency dependency groupIdorg.projectlombok/groupId artifactIdlombok/artifactId /dependencyapplication.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的配置核心是重写SecurityFilterChainConfiguration 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 ResultIPageApplyRecordVO queryList(RequestBody ApplyQueryDTO dto) { LambdaQueryWrapperApplyRecord 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); IPageApplyRecord page applyRecordMapper.selectPage( new Page(dto.getPageNum(), dto.getPageSize()), wrapper); // 组装VO返回 }分页查询中有一个性能隐患必须注意如果列表页需要展示申报人的附件数量、材料完整度等聚合字段最忌讳的写法是在循环里逐条查数据库也就是N1问题。正确的做法是查出当前页ID列表后用IN查询一次性把附件表的数据查出来然后在内存里分组组装。数据量不大时这个差异不明显但当申报人达到几百时N1查询会导致接口响应几秒钟都出不来。3.4 文件上传接口的实现与测试文件上传接口用了MultipartFile接收配合MinIO存储。实现代码如下PostMapping(/api/upload) public ResultUploadVO upload(RequestParam(file) MultipartFile file, RequestParam(bizType) String bizType) { // 1. 文件类型校验 String originalFilename file.getOriginalFilename(); String ext originalFilename.substring(originalFilename.lastIndexOf(.) 1).toLowerCase(); ListString 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) { ListReviewResult results reviewResultMapper.selectList( new LambdaQueryWrapperReviewResult() .eq(ReviewResult::getApplyId, applyId) .eq(ReviewResult::getStatus, COMPLETED)); if (results.size() 3) { throw new BusinessException(该申报人有效评审人数不足3人无法计算成绩); } ListBigDecimal 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加一键启动脚本的方式。先在项目根目录编写DockerfileFROM 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.egdfile:/dev/./urandom -jar /app.jar]这里有个容易踩的坑是时区问题Docker容器默认是UTC时区如果你的业务代码用到了LocalDate.now()或者Date类会发现数据的时间比本地时间少了8小时。必须在启动参数中加上-Duser.timezoneGMT8或者在Dockerfile里设置环境变量ENV TZAsia/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事务会静默失效这个问题更隐蔽查了很久才发现。建表时建议统一指定ENGINEInnoDB。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 常见错误排查速查表现象可能原因解决方案前端请求接口报401Token过期或未携带检查请求头是否为Authorization: Bearer xxx接口报403角色权限不足登录用户角色是否匹配PreAuthorize要求上传文件报413Nginx层限制修改Nginx的client_max_body_size参数时间显示差8小时时区配置问题容器/连接串/Jackson配置统一GMT8审查查询很慢缺少索引给申报状态、年度、用户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文件省去打印盖章的麻烦。信息化系统做到最后往往就是替用户把这些琐碎的线下操作一点点消灭掉这也是我做这个系统最有成就感的地方。
![如何用 Puppeteer 自动上传本地文件到 input[type=file] 元素](http://pic.xiahunao.cn/yaotu/如何用 Puppeteer 自动上传本地文件到 input[type=file] 元素)
