企业官网建设流程全解析

想给高校创新创业教育中心搭一套项目申报管理系统，又要贴合企业级开发规范，还要能真正落地用起来——SpringBoot+Vue+MyBatis+MySQL这套组合确实是最稳的选择。这套技术栈覆盖了后端接口开发、前端页面交互、数据持久化和数据存储四个核心环节，工作流清晰、社区资料多、上手门槛也不高。我自己在做过几个类似的教育管理类项目之后，最大的感受是：这类系统真正难的地方不在技术本身，而在业务状态的管理、多角色的权限控制、以及申报审批流程的闭环设计。这篇文章我就用企业级创新创业教育中心项目申报管理系统作为完整案例，把从需求拆解、技术选型、数据库设计到核心代码实现、踩坑排查的整个过程都整理出来，给正在做同类项目或准备用SpringBoot+Vue做毕业设计、私活项目的朋友一份可以直接参考的实践笔记。

1. 项目整体定位与需求拆解思路

1.1 这类系统的业务本质是什么

创新创业教育中心（很多学校叫“双创学院”或“创新创业学院”）的核心工作之一，就是组织学生申报各级各类创新创业项目，比如大学生创新创业训练计划（大创项目）、校级创新项目、创业孵化项目等。传统做法是学生下载Word申报书、填完发邮箱、管理员汇总后组织专家评审，整个过程文档散落、进度靠问、统计靠手工，一旦项目数量超过一两百个，管理成本会直线上升。

所以这个管理系统的核心定位，就是把“申报—审核—评审—立项—中期检查—结题”的全生命周期搬到线上。学生在线填报项目申报书，指导老师在线签署意见，双创中心管理员配置申报批次、分配评审专家，专家在线打分，系统自动汇总结果，立项后项目负责人还能提交中期报告和结题材料。每一环都有时间戳、有状态记录、有操作留痕。

我在做这类系统的需求分析时，习惯把用户故事先列出来，再倒推数据结构和接口设计，比直接开写代码要高效得多：

• 作为学生，我要能注册登录、填写申报书、上传附件、查看审核进度、收到审批驳回的原因。
• 作为指导老师，我要能看到名下学生提交的项目，在线填写审核意见，给出通过或驳回结论。
• 作为双创中心管理员，我要能创建申报批次、设定申报期间、指派评审专家、查看全校申报统计、导出报表。
• 作为评审专家，我要能查看分配给自己的项目材料，逐项打分并填写评语。
• 作为校级领导（部分系统有），我要能按学院、按批次查看立项和结题情况。

这个系统里最核心、也最容易在设计阶段做错的，就是“状态”。一个项目从草稿到结题，中间会经历多个节点，每个节点又有通过、驳回、退回修改等分支，如果不在表结构里把状态字段和流转规则设计清楚，后面写业务逻辑会非常痛苦。

1.2 核心功能模块划分

我不太建议一上来就对着SpringBoot、Vue的技术点逐项展开，那样很容易变成“为了技术而技术”。比较务实的做法是先按业务域把系统拆成几个模块，再在模块内部谈技术方案。这套系统我最终拆成了六大模块：

这六个模块基本覆盖了创新创业教育中心日常项目管理的所有场景。从工作量来看，申报审核和专家评审是两块硬骨头，前者涉及复杂的条件判断和状态流转，后者涉及多评委打分的汇总规则（平均分、去掉最高最低、按权重折算等）。其他模块的增删改查相对常规，前端表格加后端的CRUD接口就能搞定。

1.3 为什么选这套技术架构

SpringBoot + Vue + MyBatis + MySQL，在很多开发者眼里是“老三样”，甚至有人会觉得不够“高深”。但以一个长期开发和维护的角度来看，这套组合在高校和企业内部系统场景里依然是最具性价比的选择。

SpringBoot能快速搭建独立的微服务应用，内嵌Tomcat，依赖管理交给Maven或Gradle，省去大量XML配置。Vue作为前端渐进式框架，支持组件化开发，配合Element-Plus这类UI组件库，能在很短时间内搭出风格统一的后台管理界面。MyBatis把SQL和Java方法解耦，适合业务查询复杂的系统——像申报管理这种大量多表关联、动态条件查询的场面，MyBatis的灵活性和可控性反而比JPA那种自动SQL更好。MySQL则完全不需要多说，数据量在百万级以下，单库单表加合理索引足够胜任。

另外还要考虑到后期维护的问题。高校里的信息系统经常需要交给下一届学生或者第三方公司接手，SpringBoot+Vue这套技术栈的普及程度非常高，招人容易，资料丰富，不会出现“一个人走了项目就死了”的尴尬局面。

2. 数据库与后端架构设计

2.1 核心表结构的设计思路

很多刚开始做项目的同学会犯一个通病：表结构一上来就建，字段想到什么加什么，最后表之间关系混乱、冗余字段到处都是。数据库设计应该从核心业务对象出发，识别出哪些是基础数据，哪些是流程数据，哪些是关联数据，然后分门别类建模。

在这套申报管理系统里，我最终落地的核心表大致是这几类：

用户与权限相关：

• sys_user：用户主表，包含用户ID、用户名、密码（加密存储）、姓名、学号/工号、学院、电话、邮箱、头像、状态、创建时间等。这里一定要单独存学号/工号，因为学校场景下登录账号往往就是学号或工号。
• sys_role：角色表，预置ADMIN、TEACHER、STUDENT、EXPERT等角色编码。
• sys_user_role：用户与角色的关联表，实现一个用户多个角色。比如一个老师可能既是指导老师，又是某个批次的评审专家。
• sys_menu与sys_role_menu：菜单表和角色菜单权限表，用于前端动态渲染路由和按钮级别的权限控制。

申报业务相关：

• pro_batch：申报批次表，保存批次名称、申报开始时间、结束时间、评审开始时间、结束时间、状态（未开始/申报中/评审中/已结束）。有了批次表，同一套系统可以支持一年多次申报，也能区分不同年度的项目数据。
• pro_project：项目主表，一个学生申报的每一个项目对应一条记录。字段包括项目名称、项目类型（创新训练/创业训练/创业实践等）、项目级别（校级/省级/国家级）、负责人ID、指导老师ID、所属批次ID、项目简介、预算金额、当前状态、最终成绩、立项文件路径等。
• pro_application：申报详情表，和项目主表一对一或一对多。申报书内容往往很长，拆出来单独存有利于列表查询的轻量化。
• pro_attachment：附件表，保存申报书PDF、商业计划书、中期报告、结题报告等文件的路径、上传人、上传时间、附件类型。

评审相关：

• pro_review_group：评审组表，管理员创建批次时会初始化评审计划，可以按项目分组或按专家分组。
• pro_review_task：评审任务表，记录某个专家需要评审哪些项目，以及是否已完成。
• pro_review_score：评审打分表，保存每个专家对每个项目的各项指标分数、总分、评语。

过程管理相关：

• pro_change_log：项目状态变更日志表，记录项目从创建到最后结题的每一次状态变动，方便追溯。
• pro_midterm_report和pro_final_report：中期报告和结题报告表，通常结构类似，保存学生提交的内容和老师审核意见。

2.2 字段设计的几个关键经验

这里我想单独强调几个字段设计的细节，都是实际项目里踩过坑之后总结出来的：

唯一标识用自增ID还是雪花ID？如果系统仅内部使用，没有跨库分表的诉求，自增主键完全够用。如果考虑到后续可能有多个学院独立部署、数据需要合并，那么雪花ID或UUID会更合适。我在这个系统里选择的是MyBatis-Plus的自增ID配合默认的全局ID策略，简单省事，单库场景毫无压力。

状态字段用什么类型？推荐用int或tinyint存状态码，在代码里用枚举类统一定义。不建议直接存中文或英文字符串，状态多了之后不好比对，而且容易拼写不一致。

逻辑删除字段必须有。学校场景里管理员可能会误删数据，物理删掉之后要恢复就麻烦大了。我在每个业务表上都加了deleted字段（0未删、1已删），配合MyBatis-Plus的逻辑删除插件，查询时自动过滤，非常省心。

创建时间和更新时间交给数据库还是Java？我的习惯是表结构里直接定义create_time、update_time字段，使用MyBatis-Plus的自动填充功能在插入和更新时自动写入时间。这样避免每次写代码都要手动set当前时间，也能保证所有表的时间格式统一。

2.3 状态机设计：项目从草稿到结题怎么走

项目申报管理系统的核心业务逻辑，就是项目的状态流转。我把项目状态的流转设计成一个标准的状态机，代码如下：

我在代码里用一个ProjectStatusEnum来管理这些状态，同时在pro_project表里维护一个current_status字段，每次状态变更时插入一条pro_change_log记录。这样设计的好处是：前端可以根据状态码渲染对应的操作按钮，后端可以很明确地校验当前操作是否合法，管理员在后台也能看到每一个项目的完整流转历史。

有人可能会问：为什么不直接用Flowable或Activiti这类工作流引擎？我的考虑是，对于结构固定、流程不太可能频繁变更的申报审批场景，自己维护状态机和操作日志，代码更直观，出问题也好排查。如果项目后续要扩展复杂的会签、驳回任意节点、流程可视化编辑，再考虑引入Flowable即可，SpringBoot集成Flowable的资料也非常成熟，迁移成本是可控的。

2.4 后端工程结构划分

我用的是标准的Maven多模块思想，但实际落地时考虑到团队规模和部署简单性，采用了单模块内的分层分包：

src/main/java/com/edu/innovation/ ├── common/ # 通用模块：统一返回结果、异常处理、常量、枚举、工具类 ├── config/ # 配置类：MyBatisPlus配置、CORS配置、Swagger配置、JWT拦截器配置 ├── controller/ # 控制层：接收请求、参数校验、返回结果 ├── service/ # 业务层：业务逻辑实现、事务管理 ├── mapper/ # 持久层：MyBatis的Mapper接口 ├── entity/ # 实体类：对应数据库表 ├── dto/ # 数据传输对象：接收前端参数 ├── vo/ # 视图对象：返回给前端的数据封装 └── security/ # SpringSecurity相关配置、JWT工具类、自定义过滤器

分层分包的目的很明确：请求链路是 Controller → Service → Mapper，每一层只干自己该干的事。有的同学喜欢直接在Controller里写业务逻辑，项目跑起来没问题，但是一旦业务复杂到需要复用逻辑或者排查线上问题，就会非常痛苦。我在做这个项目时对团队成员提了一个硬性要求：Controller里不允许出现超过20行的业务代码，所有业务逻辑必须下沉到Service层。

2.5 为什么用MyBatis而不是MyBatis-Plus

标题里写的是MyBatis，但实际开发中，我一般会引入MyBatis-Plus作为增强插件。很多人把这两者搞混，这里简单说明一下：MyBatis-Plus是MyBatis的增强工具，只做增强不做改变，基础的CRUD方法（selectById、insert、updateById等）不需要写SQL，复杂查询依然可以用@Select注解或XML文件自定义SQL。

在这个申报系统里，MyBatis-Plus帮我们省掉了大量重复的单表CRUD代码。比如用户管理、附件管理这类简单的增删改查，直接用BaseMapper内置方法就行。而像“统计每个学院今年的申报数量”这种复杂的聚合查询，则使用XML里手写的SQL，配合<if>、<where>标签实现动态条件。

有一个实际经验可以分享一下：在写复杂查询时，尤其是多表联查，建议先在Navicat或MySQL Workbench里把SQL调试好，再粘贴到XML文件里，避免在XML里改来改去发现语法错误。调试SQL时，可以把最后一个分号去掉，多跑几遍看结果，确认无误再往代码里放。

3. 核心功能实现：从登录到评审全链路

3.1 认证授权的落地方式：JWT + Spring Security

管理系统的第一个拦路虎就是登录认证和权限控制。在这个项目里，我采用了业界主流的JWT（JSON Web Token）方案：用户登录成功之后，后端签发一个带过期时间的Token，前端把Token存在LocalStorage，每次请求时在Header里带上Authorization: Bearer <token>，后端通过拦截器解析Token并校验权限。

Spring Security在这套体系里的职责是：配置哪些URL需要认证、哪些URL可以匿名访问（比如登录接口、验证码接口、注册接口），以及在过滤器链里解析JWT并设置当前登录用户信息。核心配置用代码片段说明：

@Configuration @EnableWebSecurity public class SecurityConfig { @Autowired private JwtAuthenticationFilter jwtAuthenticationFilter; @Bean public SecurityFilterChain filterChain(HttpSecurity http) throws Exception { http.csrf().disable() .cors().and() .sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS) .and() .authorizeHttpRequests(auth -> auth .antMatchers("/api/auth/login", "/api/auth/register", "/api/auth/captcha").permitAll() .antMatchers("/api/admin/**").hasRole("ADMIN") .antMatchers("/api/student/**").hasRole("STUDENT") .antMatchers("/api/expert/**").hasRole("EXPERT") .anyRequest().authenticated() ) .addFilterBefore(jwtAuthenticationFilter, UsernamePasswordAuthenticationFilter.class); return http.build(); } }

实际开发中有一个要点：不要把Spring Security的配置做得太死板。学校项目里角色权限经常要临时调整，比如“这次让辅导员也帮忙审核一下”，如果你把所有接口都严格绑定到角色上，后续改动要动代码。我在系统里做了一个相对灵活的方案：后端只校验登录状态和基础角色，具体按钮和页面的操作权限通过sys_menu和sys_role_menu控制，管理员在前端角色管理页面就能给某个角色勾选菜单权限。这样既保证了安全性，又具备可配置性。

3.2 申报批次的创建与申报窗口控制

申报批次是整个申报流程的时间起点。管理员创建一个批次时，需要填写批次名称、申报开始时间、申报结束时间、评审开始时间、评审结束时间。后端在保存批次的时候，要做几件事：

校验时间合法性。申报结束时间必须晚于申报开始时间，评审开始时间必须晚于申报结束时间，否则提示前端“时间配置有误”。这个校验既要在前端表单里做一道，又要在后端Controller里做一道，防止有人绕过前端直接调接口。

控制申报窗口。学生提交申报书时，后端要检查当前时间是否在申报批次的有效窗口内。如果申报已经截止，返回“当前不在申报时间内，无法提交”。这个逻辑看似简单，但很容易被遗漏，一旦漏掉，就会出现学生在截止日期之后还能提交材料的bug。

批次状态的自动流转。我采用了定时任务加懒更新的方式：有一个@Scheduled定时任务每分钟跑一次，把所有批次的状态刷新一遍（未开始→申报中→评审中→已结束），同时在用户查询批次时也会做一次状态校正。这样即使定时任务有延迟，也不会影响用户看到的批次状态。

3.3 学生申报流程里的关键逻辑

学生登录后进入项目申报页面，整个申报流程分为四步：填写基本信息 → 填写申报书详情 → 上传附件 → 提交审核。我并不建议把这四步一股脑做一个表单，因为申报书内容字段很多（项目名称、项目类型、研究背景、研究内容、创新点、进度安排、预期成果、经费预算等），用分步表单的交互体验更好，也方便在后台做分步的草稿保存。

学生每完成一步，前端调一次保存接口，后端把数据更新到pro_project或pro_application表，项目状态保持“草稿”。等学生点击“提交审核”，后端做一次完整性校验：

• 必填字段是否都填了（比如项目名称不能为空、经费预算必须大于0）。
• 附件是否上传完整（比如申报书PDF必须存在）。
• 指导老师是否已选择（有的学校要求申报时必须指定指导老师）。
• 当前时间是否在申报窗口内。

校验通过后，项目状态从“草稿”改为“已提交待指导老师审核”，同时往pro_change_log表里插入一条状态变更记录。这样整个申报过程的数据是逐步沉淀的，不会因为学生突然关闭浏览器而丢失所有内容。

3.4 专家评审模块的分数汇总策略

专家评审是我个人认为整个项目里业务趣味性最强的一部分。管理员在后台把一个批次的项目批量分配给若干专家，每个专家登录后可以看到自己的评审任务列表，点进某个项目之后，能看到项目申报书、附件材料，然后按指标打分。

打分指标我设计了几个维度，比如立项意义、研究方案、创新性、经费合理性、预期成果等，每个维度满分十分，最后合计得到总分。数据库里pro_review_score表每个专家对每个项目会有一行记录，包含各项小分、总分、评审建议。管理员在“评审结果”页面可以看到每个项目的平均分、专家人数以及分数汇总明细。

这里有一个业务细节很关键：评审过程中，专家不应该看到其他专家的打分，否则先评完的专家会影响后面专家的判断。我的实现方案是，专家端接口只查询当前专家自己的打分记录，不提供查询项目平均分的接口；等评审结束、管理员手动“发布评审结果”之后，才允许评审专家查看最终的平均分和立项名单。

汇总分数的实现逻辑也要注意精度。我用BigDecimal来参与所有计算，避免double或float带来的精度丢失问题。如果学校要求“去掉一个最高分、去掉一个最低分再取平均”，就在Service层写一个单独的聚合方法，先排序再剔除两端值，最后保留两位小数。这类规则最好做成配置项，放在sys_config表里，方便不同学校随时调整。

3.5 报表统计模块：让数据说话

管理系统做到最后，“统计报表”往往成了领导最关注的功能。这个系统里我做了四个报表页面：全校申报情况统计、各学院申报对比、项目级别分布、结题成果汇总。

最大的一张表（申报情况统计）用到了典型的连表查询加分组聚合。示例SQL如下：

SELECT b.id AS batch_id, b.batch_name, COUNT(p.id) AS total_count, SUM(CASE WHEN p.current_status >= 1 THEN 1 ELSE 0 END) AS submitted_count, SUM(CASE WHEN p.current_status >= 3 THEN 1 ELSE 0 END) AS approved_count, SUM(CASE WHEN p.current_status = 6 THEN 1 ELSE 0 END) AS finished_count FROM pro_batch b LEFT JOIN pro_project p ON p.batch_id = b.id GROUP BY b.id, b.batch_name ORDER BY b.create_time DESC

报表数据量通常不大，真正影响性能的是多条件筛选。我的经验是：尽量把筛选条件在SQL里做掉，不要让Java层拿到全表数据再stream过滤，那样数据量上来之后接口会明显变慢。同时给batch_id、current_status、user_id等高频筛选字段加上联合索引，查询性能会有质的提升。

4. 关键代码实现与部署经验

4.1 项目初始化与依赖版本选择

在开始写代码之前，环境准备是最容易踩坑的地方。SpringBoot的版本选择非常关键，太高或太低都会带来一堆兼容性问题。我在这套系统里使用SpringBoot 2.7.x，对应JDK 1.8或JDK 11；MyBatis-Plus版本用了3.5.x，Spring Security直接随SpringBoot版本兜底。前端方面，Vue 2.7配合Element-UI 2.15，或者Vue 3配合Element-Plus，都是目前稳定可用的方案。考虑到与后端开发人员的技术栈匹配度，我当时选的是Vue 3 + Element-Plus，因为后续组件生态和文档更新更活跃。

Maven依赖中一个比较容易忽略的点是连接MySQL 8.0以上版本时，需要显式引入mysql-connector-java（较新版本的groupId为com.mysql:mysql-connector-j），同时JDBC连接串需要添加时区参数：

spring: datasource: url: jdbc:mysql://localhost:3306/innovation_db?useUnicode=true&characterEncoding=utf-8&serverTimezone=Asia/Shanghai&useSSL=false&allowPublicKeyRetrieval=true username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver

这里有两个细节容易翻车。serverTimezone=Asia/Shanghai不配置的话，数据库连接会报The server time zone value is unrecognized错误；allowPublicKeyRetrieval=true不配置的话，使用MySQL 8.0的caching_sha2_password认证方式时，首次连接会报Public Key Retrieval is not allowed。这几个参数每次都记不住也没关系，直接当模板用就行。

4.2 后端核心接口的编写示范

以“学生提交申报书”接口为例，我给出一个精简但完整度较高的代码示意，大家可以直接在这个基础上做扩展：

@RestController @RequestMapping("/api/student/project") public class StudentProjectController { @Autowired private ProjectService projectService; @PostMapping("/submit") public Result<Void> submit(@RequestBody @Validated ProjectSubmitDTO dto) { // 从SecurityContext获取当前登录用户ID Long userId = SecurityUtils.getCurrentUserId(); projectService.submitProject(userId, dto); return Result.success(); } }

Service层实现核心业务校验和状态流转：

@Service @Transactional(rollbackFor = Exception.class) public class ProjectServiceImpl implements ProjectService { @Autowired private ProjectMapper projectMapper; @Autowired private BatchMapper batchMapper; @Autowired private ChangeLogMapper changeLogMapper; @Override public void submitProject(Long userId, ProjectSubmitDTO dto) { // 1. 查询项目是否属于当前用户 Project project = projectMapper.selectById(dto.getProjectId()); if (project == null || !project.getCreatorId().equals(userId)) { throw new BusinessException("项目不存在或无权操作"); } // 2. 校验当前状态必须为草稿(0) if (!ProjectStatusEnum.DRAFT.getCode().equals(project.getCurrentStatus())) { throw new BusinessException("当前状态不允许提交"); } // 3. 校验申报窗口时间 Batch batch = batchMapper.selectById(project.getBatchId()); if (batch == null || !isWithinApplyPeriod(batch)) { throw new BusinessException("当前不在申报时间内"); } // 4. 更新项目内容、状态为已提交 project.setProjectContent(dto.getProjectContent()); project.setBudget(dto.getBudget()); project.setCurrentStatus(ProjectStatusEnum.SUBMITTED.getCode()); projectMapper.updateById(project); // 5. 记录状态变更日志 ChangeLog log = new ChangeLog(); log.setProjectId(project.getId()); log.setFromStatus(ProjectStatusEnum.DRAFT.getCode()); log.setToStatus(ProjectStatusEnum.SUBMITTED.getCode()); log.setOperatorId(userId); log.setRemark("学生提交申报书"); changeLogMapper.insert(log); } }

这段代码里有两个值得注意的地方：第一，所有业务方法加上@Transactional事务注解，保证状态更新和日志插入要么一起成功、要么一起回滚；第二，状态校验一定放在业务逻辑的最前面，防止前后端状态不同步时出现脏操作。

4.3 前端Vue项目的工程化搭建

前端部分我使用Vue CLI或Vite创建项目，统一安装了vue-router、axios、pinia、element-plus。目录结构按模块划分：

src/ ├── api/ # 接口定义文件，按模块拆分：auth.js、project.js、admin.js等 ├── assets/ # 静态资源 ├── components/ # 公共组件：UploadFile.vue、StatusTag.vue、PageHeader.vue等 ├── router/ # 路由配置，包含动态路由生成逻辑 ├── store/ # Pinia状态管理：userStore、appStore ├── views/ # 页面组件：login、student、teacher、admin、expert等 ├── utils/ # 工具函数：request.js（axios封装）、auth.js、validate.js └── App.vue

utils/request.js是前端请求的核心封装，所有的HTTP请求都会经过它。我在这里统一处理了Token注入、响应拦截、错误提示和401跳转：

import axios from 'axios' import { ElMessage } from 'element-plus' import router from '@/router' import { useUserStore } from '@/store/user' const request = axios.create({ baseURL: '/api', timeout: 15000 }) request.interceptors.request.use(config => { const userStore = useUserStore() const token = userStore.token || localStorage.getItem('token') if (token) { config.headers['Authorization'] = `Bearer ${token}` } return config }) request.interceptors.response.use( response => { const res = response.data if (res.code !== 200) { ElMessage.error(res.message || '请求失败') return Promise.reject(new Error(res.message)) } return res }, error => { if (error.response && error.response.status === 401) { localStorage.removeItem('token') router.push('/login') } ElMessage.error(error.response?.data?.message || '网络异常，请稍后重试') return Promise.reject(error) } ) export default request

一个很容易被忽略的细节是：前端的跨域问题。本地开发时，前端跑在8080端口，后端跑在8081端口，浏览器默认会拦截跨域请求。我的处理方案是：生产环境通过Nginx做反向代理将/api转发到后端，开发环境在vue.config.js里配置代理：

module.exports = { devServer: { port: 8080, proxy: { '/api': { target: 'http://localhost:8081', changeOrigin: true } } } }

这样前端代码里所有请求都写/api/xxx，开发和生产环境都能正确转发，不用在代码里写死IP和端口。

4.4 评审模块前端页面要点

评审页面是整个系统里用得最多的前端页面之一。专家的操作路径是：登录 → 我的评审任务列表 → 点进某一个项目 → 查看申报材料 → 在线评分 → 提交评分结果。

评审任务列表我用了一个筛选条件加表格的组合：默认展示“待评审”状态的任务，提供“已完成”和“全部”两个Tab切换。表格里会显示项目名称、申报人姓名、项目类型、申报批次、状态（待评审/已评审）、操作按钮。

项目详情页面采用了左右分栏的布局：左侧是项目申报书的详情（标题、简介、内容、经费表、预期成果），右侧是当前项目的附件材料列表，附件支持PDF在线预览和下载。继续往下是评分表单，五个评分维度各一行，每项使用el-input-number限定位数，评分框旁边有清晰的维度说明，这是我在多次用户体验反馈后加上的。

提交评分的时候，前端做一个最低完整性校验，比如“所有评分项都不能为空、总分自动计算”：

const total = scoreFields.reduce((sum, field) => sum + Number(field.value || 0), 0) form.totalScore = total.toFixed(2)

只有全部字段填完，提交按钮才会置为可用。这个细节虽然小，但能很大程度减少后端的无效请求和专家的误操作。

4.5 项目的部署与上线流程

系统开发完成后，部署是另一个容易翻车的环节。我通常采用前后端分离的部署方式：前端构建出来的静态资源（dist目录）由Nginx提供访问，后端打包成Jar包通过systemd或supervisor守护运行，MySQL单独部署在服务器本地或云数据库上。

Nginx配置中一个比较实用的示例（仅展示关键部分）：

server { listen 80; server_name your-domain-or-ip; # 前端静态资源 root /opt/innovation-frontend/dist; index index.html; # 解决Vue路由刷新404问题 location / { try_files $uri $uri/ /index.html; } # 后端API反向代理 location /api/ { proxy_pass http://127.0.0.1:8081; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } # 上传文件的访问路径 location /files/ { alias /opt/innovation-upload/; } # 静态资源缓存优化 location ~* \.(js|css|png|jpg|jpeg|gif|svg|woff2?)$ { expires 7d; add_header Cache-Control "public"; } }

注意try_files这一行，Vue Router如果使用history模式，刷新页面时如果不配置这个，会直接404。很多新手部署完之后发现首页能打开、但刷新内页就报错，问题就出在这里。如果不想处理这个，前端也可以用hash模式，URL里会多个#号，但对体验不是特别友好，我还是建议用history模式加Nginx配置。

5. 常见问题排查与优化技巧

5.1 MyBatis动态SQL使用时的坑

MyBatis的XML写动态SQL，最常见的坑是条件判断中数值类型的判空问题。比如项目的状态字段是Integer currentStatus，想要实现“当状态不为空时按状态查询”，很多同学会写成：

<if test="currentStatus != null and currentStatus != ''"> AND current_status = #{currentStatus} </if>

这在字符串类型下没问题，但Integer类型本来就不可能等于空字符串，所以currentStatus != ''这个判断是多余的，甚至有潜在问题。正确的写法是只判断null：

<if test="currentStatus != null"> AND current_status = #{currentStatus} </if>

另外，多条件查询时一定要用<where>标签代替手写WHERE 1=1，<where>标签可以自动处理掉第一个AND，而WHERE 1=1虽然也能跑，但不够优雅，而且会影响部分数据库的索引选择。

5.2 附件上传的大小限制和类型校验

SpringBoot默认的单文件上传大小限制只有1MB，这在申报书PDF和商业计划书的场景下完全不够用。我一般在application.yml里调大：

spring: servlet: multipart: max-file-size: 50MB max-request-size: 100MB

同时在Controller层做文件类型白名单校验。注意不能只校验文件后缀名，因为后缀可以被伪造：

String originalFilename = file.getOriginalFilename(); String extension = StringUtils.getFilenameExtension(originalFilename); if (!Arrays.asList("pdf", "doc", "docx", "xls", "xlsx", "zip", "rar").contains(extension.toLowerCase())) { throw new BusinessException("不支持的文件类型"); } // 更严谨的做法是读取文件的Content-Type或者用Tika嗅探真实文件类型

上传文件的存储路径也建议放在服务器的某个固定目录（比如/opt/innovation-upload），不要存在项目的classpath里，否则打包替换Jar包的时候文件就丢了。

5.3 数据库表名或字段名冲突

MySQL里user、order、group都是保留字，表名或字段名如果叫这些，SQL执行时会报语法错误。我在项目中给用户表起名sys_user，给评审组表起名pro_review_group，从根源上规避了这个问题。如果确实用了保留字，可以用反引号括起来：

SELECT * FROM `order`

但反引号在跨数据库迁移时会带来兼容性问题，不如从设计阶段就避开。

5.4 导出Excel的乱码问题

申报管理系统基本都会用到Excel导出功能，我用的是EasyExcel。这里有个很容易被忽视的坑：给前端返回Excel时，需要在响应头里设置编码和文件名。文件名里有中文时，如果不做URL编码处理，下载下来的文件名就是一堆乱码：

String fileName = URLEncoder.encode("申报情况统计.xlsx", "UTF-8"); response.setHeader("Content-Disposition", "attachment;filename=" + fileName);

而且文件名的编码处理和不同浏览器的兼容性有关，做一次URLEncoder之后，绝大部分浏览器都能正确识别中文文件名，这个经验可以直接抄作业。

5.5 接口响应速度慢的排查思路

如果某天管理员反馈“统计报表接口转圈圈转了好几秒”，我一般的排查路径是：先看接口是否走了数据库索引，用EXPLAIN看执行计划；再看是否出现了N+1查询问题，也就是循环里查数据库。这两种情况占了后端性能问题的大头。

我的pro_project表建议加的联合索引：

ALTER TABLE pro_project ADD INDEX idx_batch_status (batch_id, current_status); ALTER TABLE pro_project ADD INDEX idx_creator (creator_id);

对于统计报表这类场景，数据量不大的时候完全够用。如果学校数据量增长到几百万条再考虑做定时任务预聚合或者引入ES。现阶段不要过度设计，没必要为了“高并发”去引入缓存中间件、消息队列，先把业务闭环跑通，再去优化性能也不迟。

6. 这个项目还能怎么扩展

说完实现细节，再聊聊扩展方向。这个系统的核心架构决定了它可以很容易地往几个方向演进。

流程引擎化。目前的状态机管理方式适合结构固定的审批流。当学校提出“指导老师审核后还要院系领导审核”或者“省级项目要增加终审答辩环节”这类需求时，状态机的维护成本会上升。这时候就可以考虑引入Flowable工作流引擎，把审批流程的定义从代码中剥离出来，管理员可以通过在线设计器调整审批节点。SpringBoot集成Flowable做工作流开发，目前资料已经非常完善，学习成本也不高。

消息提醒增强。现在系统的通知主要以站内信和页面角标为主，如果希望用户“被叫醒”，可以接入邮件和短信通知。例如项目被驳回时自动发邮件提醒学生，立项结果发布时给专家发短信通知。实现方案也不复杂，Spring Boot的spring-boot-starter-mail就能发邮件，短信可以对接阿里云短信SDK，把通知逻辑抽成一个独立的NotificationService，不会污染现有业务代码。

数据可视化看板。目前的统计报表以表格呈现为主，后续可以用ECharts把各学院申报情况、项目类型分布、历年立项趋势做成大屏展示，放在双创中心的大厅屏幕上滚动播放。前端引入ECharts的成本很低，数据接口后端已经具备了，只需要新增几个聚合接口即可。

移动端适配。老师和专家经常要在手机上审核，响应式页面的体验往往不如原生App。如果团队有精力，可以用Vue3的移动端UI库（Vant）把核心流程（审批、评审、查看进度）做一个小程序或H5版本，后端接口不需要改动太多，因为前后端分离架构已经把复用的成本降得很低了。

多租户级联。如果这套系统要推广到多所学校使用，就需要考虑租户隔离，在表里加tenant_id字段，查询时统一拼接租户条件。这部分改动看起来简单，但影响面很广，建议从项目初期就预留好扩展位。

最后分享一点我个人的感受

做完这套系统，我最深的一点体会是：像这样的管理类系统，业务复杂度和边界条件是远超预期的。一个“学生提交项目”的按钮背后，涉及时间窗口校验、状态校验、指导老师绑定、附件完整性校验、日志记录等一连串逻辑，少任何一环，系统在真实使用中都可能出问题。单纯会写增删改查页面不难，难的是把业务上的各种可能性想清楚，然后用代码一层层拦住错误操作、记录操作轨迹、给出友好提示。这也是为什么我建议做这类项目的朋友，多去跟真实的用户（双创中心的老师、申报的学生）聊一聊，很多设计上的细节，比如“申报截止时间要不要自动顺延”“驳回后学生能不能重新编辑再提交”，只有拿到真实需求才能做好决策。

另外，如果你想通过这类项目面试Java岗位，我建议你把状态机的设计、JWT认证流程、动态权限配置、报表统计SQL这四块吃透，面试官最常问的就是这些点。做的时候多留意“为什么这样设计”，比单纯堆功能要重要得多。这套系统的完整源码和数据库脚本我做了脱敏处理之后会整理出来，可以直接导入数据库运行，前后端项目都能用IDE打开调试。需要的朋友可以参考里面的代码结构和设计思路去扩展自己的项目，有问题也欢迎留言一起讨论。