企业官网建设流程全解析

做了这么多年的Spring Boot实际项目，我拿到“奖助学金管理系统”这类题目的时候，第一反应不是马上写代码，而是先把业务流程捋顺。因为奖助学金的审核链路很长——学生申报、班级评议、院系审核、校级复核、名单公示、资金发放，每一步都涉及不同角色、不同状态和大量纸质单据，如果一开始不把数据模型理顺，后面写业务逻辑的时候一定会被各种“状态不一致”的问题反复折腾。这篇文章我主要围绕Spring Boot实现奖助学金管理系统的完整思路来展开，把需求拆解、技术选型、数据库设计、核心模块实现、部署调试和常见坑位都讲一遍，给正在做类似毕业设计或中小型信息管理项目的开发者一份可以抄作业的参考。

这套系统本质上解决的是“多角色协同处理结构化流程”的问题：学生提交申请，老师逐级审核，管理员做全局配置和统计，而所有操作痕迹都需要被记录、可追溯。用Spring Boot来落地这类系统，最大的优势在于生态成熟、上手快、后期维护成本低，尤其是配合MyBatis Plus这种半自动ORM框架之后，单表CRUD几乎不用写SQL，真正需要动脑子的都集中在业务规则上。

先说结论：这套系统我实际跑下来很稳，核心流程从“学生提交申请”到“校级审核完成”全链路通畅，代码量适中，数据库设计合理，非常适合作为毕设或课设项目，也适合作为企业内部小型业务系统的改造模板。

1. 项目整体定位与核心需求拆解

1.1 传统奖助学金管理的真实痛点

很多人觉得奖助学金管理不就是“填表-审批-发钱”吗，为什么值得专门做一套系统？我实际接触过的用户反馈里，真正让管理员头疼的是这几点：

第一，纸质申请表流转效率极低。一个学年两个学期，涉及国家奖学金、国家助学金、校内优秀学生奖学金、单项奖学金等多个项目，每个项目都有申请条件、名额限制、截止时间。学生填纸质表，辅导员收了之后核验成绩和家庭情况，院系再统计上报，一步出错就得从头再走一遍。

第二，资格审核的数据分散在不同的Excel表格里。绩点排名在教务处系统，家庭经济困难认定结果在学工系统，处分记录在另一个系统，审核老师需要手动跨系统比对，既费时又容易漏看。我在系统设计里把学生的基本信息、成绩排名、困难认定等级这些字段统一冗余到一张考核表中，虽然会占用一点存储，但审核时只需要一次查询就能完成资格判断，实用价值远大于存储开销。

第三，过程追溯几乎为零。奖学金评审讲究“公平、公正、公开”，一旦学生或家长对结果有异议，管理员需要翻查历史材料，但纸质材料一旦归档，查找起来非常困难。电子化系统天然解决了这个问题，每一次审核操作都会写入操作日志，申请人可以查看文章当前停在哪一步，管理员可以按时间线回溯全部审核记录。

1.2 系统角色与业务流程梳理

在动手建表之前，我先把角色和流程定下来。这套系统的核心角色有五类：

• 学生：查看奖助项目信息、在线提交申请、上传证明材料、查看审核进度和最终结果
• 辅导员：初审本班学生的申请，核验材料真实性，填写评议意见
• 院系审核员：复核辅导员提交上来的结果，按名额分配给各班级
• 校级管理员：配置奖助项目、维护学生基础信息、发布公示、确认发放名单
• 财务与发放员：负责对接最终名单，标记资金发放状态

流程上我采用的是经典的多级审批链：学生提交 → 辅导员初审 → 院系复审 → 学校终审 → 公示 → 发放登记。每一步都对应申请记录中的一个状态字段，保证流程单向流动，不接受跳级审批。这个设计在业务上完全合理，因为奖助学金的审核讲究逐级负责，每个节点都留痕，出了问题能直接定位到具体审核人。

1.3 功能模块规划

整个系统我拆成了五个功能模块：

• 学生信息管理：导入和维护学生基础档案，包括学号、姓名、专业、绩点、家庭年收入、困难认定等级
• 奖助项目管理：管理员可配置项目类型、金额、名额总数、申请开放时间、申请条件模板
• 在线申请与材料上传：学生端提交申请时按项目要求上传佐证材料，系统自动校验必填项
• 分级审核与过程跟踪：不同角色进入各自的待办列表，完成审核或退回补正，全程记录操作日志
• 公示管理、统计报表与发放登记：审核完成后进入公示流程，公示期结束后由管理员确认发放名单，系统按院系、项目类型汇总统计

这五个模块覆盖了奖助学金业务从配置到发放的全部环节，前端页面加上后端接口一共不到30个功能点，工作量适中，既能体现Spring Boot的全栈开发能力，又不至于因为过度设计把自己拖垮。

2. 技术选型与项目工程搭建

2.1 技术栈选型的思路

这个项目我选的组合是Spring Boot 2.7 + MyBatis Plus 3.5 + MySQL 8.0 + Thymeleaf，Java版本用的JDK 1.8。选这套组合的理由很直接：

Spring Boot 2.7是生产环境里占有率最高的版本之一，相关资料多、生态稳定，遇到问题几乎都能搜到解决方案。MyBatis Plus比原版MyBatis更省事的地方在于，单表查询不用写XML映射文件，内置的BaseMapper直接提供insert、selectPage、updateById这些通用方法，能省掉至少三分之一的基础CRUD代码。Thymeleaf作为服务端渲染模板，做管理后台类的项目比前后端分离省心太多，不用考虑跨域、不用单独部署前端，一个jar包丢到服务器上就能跑。

有人可能会问，为什么不用Spring Boot 3.x？我个人的实践体会是，Spring Boot 3要求JDK 17起步，虽然性能更好，但对很多毕设或者小团队项目来说，JDK 8的环境可能更普遍，而且MyBatis Plus对Spring Boot 3的适配在一些老版本上存在兼容问题。如果不想在环境上浪费调试时间，2.7是稳妥选择。

2.2 工程目录与项目初始化

工程名我建议命名为fund-system，采用Maven标准目录结构：

fund-system ├── src/main/java/com/example/fund │ ├── controller │ ├── service │ ├── mapper │ ├── entity │ ├── config │ ├── common │ └── FundSystemApplication.java ├── src/main/resources │ ├── mapper │ ├── templates │ ├── static │ └── application.yml └── pom.xml

初始化方式最简单的是用Spring Initializr，如果网络不方便也可以直接在pom.xml里手动引入依赖。我用到的核心依赖如下：

<parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.7.18</version> </parent> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-thymeleaf</artifactId> </dependency> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.3</version> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>8.0.33</version> </dependency> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <optional>true</optional> </dependency> </dependencies>

这套依赖清单不复杂，但已经覆盖了Web层、模板层、持久层和实体简化工具。Lombok的使用能在实体类上省掉大量getter/setter模板代码，让代码整体干净很多。

2.3 基础配置与通用封装

application.yml里需要配置数据源、MyBatis Plus的映射路径和逻辑删除配置。逻辑删除这块特别建议打开，因为奖助学金的审核记录和申请记录不允许物理删除，即使学生撤回申请，数据库里也要保留完整的历史记录。

server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/fund_system?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: root thymeleaf: cache: false mybatis-plus: mapper-locations: classpath:/mapper/**/*.xml global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0

另外我封装了一个Result类作为统一返回体，包含code、message、data三个字段，前端页面通过这个结构判断请求是否成功。这类通用工具虽然代码不多，但能让Controller层的方法签名干净不少，避免每个接口都返回不同的数据结构。

3. 数据库设计与核心表结构

3.1 表结构总览与设计思路

奖助学金系统的核心是三条主线：用户与角色、项目与条件、申请与审核。

我设计了以下核心表：

• sys_user：登录账号信息，存放用户名、加密密码、角色类型
• student_info：学生拓展信息，存放学号、姓名、专业班级、绩点、困难认定等级
• funding_item：奖助项目定义，存放项目名称、类型、金额、名额总数、申请起止时间
• funding_application：学生申请记录，存放申请项目ID、学生ID、申请状态、提交时间
• audit_record：审核流水表，记录每一级审核的意见和操作人、操作时间
• public_notice：公示记录表，存放公示标题、内容、公示期起止时间
• award_payment：发放记录表，存放审核通过并进入发放阶段的项目名单及发放状态

设计这几张表的时候，我一直提醒自己的一件事是：不要为了追求范式把表拆得过于零散。奖助学金业务的核心链路是申请和审核，这两条链路的数据访问频率最高，所以我把学生信息里的关键评判字段（绩点、困难等级、处分情况）直接冗余到了学生表中，查询时减少一次关联。虽然理论上这些字段可能由基础数据平台统一维护，但在独立系统内部做冗余是完全可接受的权衡。

3.2 核心表的建表语句分析

学生信息表是整个系统的数据基座，字段设计如下：

CREATE TABLE student_info ( id BIGINT PRIMARY KEY AUTO_INCREMENT, student_no VARCHAR(20) NOT NULL UNIQUE, name VARCHAR(50) NOT NULL, gender TINYINT DEFAULT 0, college VARCHAR(100) COMMENT '学院', major VARCHAR(100) COMMENT '专业', class_name VARCHAR(50) COMMENT '班级', gpa DECIMAL(4,2) COMMENT '绩点', rank_percent DECIMAL(5,2) COMMENT '专业排名百分比', family_income DECIMAL(10,2) COMMENT '家庭年收入', poverty_level TINYINT COMMENT '困难等级 0无 1一般困难 2困难 3特别困难', violation_flag TINYINT DEFAULT 0 COMMENT '违纪记录标记', deleted TINYINT DEFAULT 0, create_time DATETIME, update_time DATETIME ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

申请记录表是业务核心，我用一个status字段驱动整个流程：

CREATE TABLE funding_application ( id BIGINT PRIMARY KEY AUTO_INCREMENT, application_no VARCHAR(32) NOT NULL, student_id BIGINT NOT NULL, item_id BIGINT NOT NULL, status TINYINT DEFAULT 0 COMMENT '0草稿 1待辅导员初审 2待院系复审 3待校级终审 4已通过 5被退回 6学生撤回 7公示中 8已发放', apply_reason TEXT, material_json TEXT COMMENT '上传材料路径集合', submit_time DATETIME, update_time DATETIME, deleted TINYINT DEFAULT 0 ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这里要重点说明一下状态机的设计。我没有把审核结果拆成多个字段，而是用一个单字段的整型状态值贯穿全流程，配合容易判断的枚举。这样做的好处是查询“当前待我审核”时非常简单，比如一个辅导员只需要查status = 1的记录就能得到全部待初审列表，不用写复杂的联表条件。状态流转完全由Service层控制，每个流转动作都要写入audit_record表，这样既保证查询效率，又不丢失审核过程。

3.3 状态字段与流程约束

数据库层面能做的流程约束有限，更多的约束要在Service层保证。我实际开发中踩过的一个坑是：学生重复提交同一项目的申请，因为没有做唯一约束，导致数据库里出现两条并存的待审记录。后来我在funding_application表里为(student_id, item_id)加了逻辑上的唯一判断，并通过Service层在提交前校验“当前项目是否已经存在状态小于4的记录”，如果存在则阻止重复提交。这个校验逻辑虽然简单，但如果没有加，后面统计名额、生成名单的时候一定会乱。

还有一个经验是金额字段统一用DECIMAL(10,2)，不要用FLOAT或DOUBLE，否则统计时会出现精度差异。奖助学金金额精确到分，任何浮点误差都会在财务对账时放大成不可接受的问题。

4. 核心功能模块的实现

4.1 基于角色的登录与权限控制

登录模块看似简单，但权限设计决定了整个系统是否可用。我没有引入复杂的安全框架，而是用拦截器加当前用户上下文的方式做了一套轻量级权限控制，代码量少、逻辑直观。

用户表里role字段区分角色，登录成功后把用户对象存入Session，拦截器读取请求路径前缀与角色所需权限做匹配：

@Component public class AuthInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { HttpSession session = request.getSession(); SysUser user = (SysUser) session.getAttribute("loginUser"); if (user == null) { response.sendRedirect("/login"); return false; } String uri = request.getRequestURI(); if (uri.startsWith("/admin/") && !"ADMIN".equals(user.getRole())) { response.setContentType("text/html;charset=utf-8"); response.getWriter().write("<script>alert('无权访问');history.back();</script>"); return false; } return true; } }

密码存储务必使用BCrypt加密，我在项目里用的是spring-security-crypto库中的BCryptPasswordEncoder，单独引入这个依赖而不引入全套Spring Security，既满足加密需求又不增加配置复杂度。明文密码在数据库里是绝对的安全红线，这一点无论项目多小都不要妥协。

4.2 学生在线申请功能

学生申请功能要解决三个问题：能看到哪些项目、提交哪些材料、如何避免重复申请。

项目可见性通过时间窗口控制，学生进入申请列表页后，后端查询当前时间在申请起止范围内的项目，同时把项目条件说明展示出来。提交申请时，Controller接收表单数据，Service层完成资格校验：

public Result submitApplication(Long studentId, Long itemId, String reason, MultipartFile[] files) { // 校验项目是否存在且在申请期内 FundingItem item = fundingItemMapper.selectById(itemId); LocalDateTime now = LocalDateTime.now(); if (item.getApplyStart().isAfter(now) || item.getApplyEnd().isBefore(now)) { return Result.error("当前不在申请时间内"); } // 校验是否已经申请过 LambdaQueryWrapper<FundingApplication> queryWrapper = new LambdaQueryWrapper<>(); queryWrapper.eq(FundingApplication::getStudentId, studentId) .eq(FundingApplication::getItemId, itemId) .in(FundingApplication::getStatus, 0, 1, 2, 3, 4, 7, 8); if (fundingApplicationMapper.selectCount(queryWrapper) > 0) { return Result.error("您已提交过该项目的申请，请勿重复提交"); } // 保存记录 FundingApplication application = new FundingApplication(); application.setApplicationNo(generateApplicationNo()); application.setStudentId(studentId); application.setItemId(itemId); application.setStatus(1); application.setApplyReason(reason); application.setSubmitTime(LocalDateTime.now()); fundingApplicationMapper.insert(application); return Result.success("提交成功"); }

材料上传我用的是本地存储，把文件写到服务器上的upload目录，路径存到material_json字段中。上传文件时一定要做类型白名单校验和大小限制，比如只允许jpg、png、pdf，单文件不超过5MB。之前见过有人因为没限制上传大小，一个几十MB的高清扫描件直接把服务器磁盘塞满了。

4.3 多级审核流程实现

审核是这个系统里最有技术含量也最需要小心处理的部分。我的实现方案是：不同角色进入各自的待办列表，执行审核时统一调用同一个Service方法，通过状态值决定下一步流向。

核心代码逻辑如下：

@Transactional public Result audit(Long applicationId, Long auditorId, Integer approved, String comment) { FundingApplication application = fundingApplicationMapper.selectById(applicationId); if (application == null) { return Result.error("申请记录不存在"); } // 当前状态下可执行审核的角色映射 if (application.getStatus() == 1) { // 辅导员初审 if (!"COUNSELOR".equals(currentRole)) return Result.error("无权审核"); } else if (application.getStatus() == 2) { // 院系复审 if (!"COLLEGE_AUDITOR".equals(currentRole)) return Result.error("无权审核"); } else if (application.getStatus() == 3) { // 校终审 if (!"ADMIN".equals(currentRole)) return Result.error("无权审核"); } else { return Result.error("当前状态不可审核"); } AuditRecord record = new AuditRecord(); record.setApplicationId(applicationId); record.setAuditorId(auditorId); record.setResult(approved == 1 ? 1 : 0); record.setComment(comment); record.setCreateTime(LocalDateTime.now()); auditRecordMapper.insert(record); // 状态流转 if (approved == 1) { if (application.getStatus() == 1) { application.setStatus(2); } else if (application.getStatus() == 2) { application.setStatus(3); } else if (application.getStatus() == 3) { application.setStatus(4); } } else { application.setStatus(5); // 退回 } fundingApplicationMapper.updateById(application); return Result.success("审核完成"); }

这段代码里我加了@Transactional注解，保证审核记录插入和申请状态更新要么同时成功要么同时失败，不会出现“意见记了但状态没变”的情况。这个方法被三个审核端共用，状态判断自然隔离了不同角色的权限边界，非常实用。

4.4 数据统计与名单导出

审核流程走完之后还要做数据导出。很多同学容易忽略导出模块，实际使用中这是高频功能——校级管理员需要按学院汇总名额使用情况、按项目类型统计申请人数和通过人数。

我用的方案是后端查询后用EasyExcel导出，支持.xlsx格式。核心思路是先构建列表数据，再写ExcelWriter：

public void exportApprovedList(Long itemId, HttpServletResponse response) throws IOException { List<FundingApplication> list = fundingApplicationMapper.selectApprovedList(itemId); List<ExportRow> rows = list.stream().map(a -> { ExportRow row = new ExportRow(); row.setStudentNo(a.getStudentNo()); row.setName(a.getName()); row.setCollege(a.getCollege()); row.setGpa(a.getGpa()); row.setPovertyLevel(a.getPovertyLevel()); return row; }).collect(Collectors.toList()); response.setContentType("application/vnd.openxmlformats-officedocument.spreadsheetml.sheet"); response.setCharacterEncoding("utf-8"); String fileName = URLEncoder.encode("公示名单", "UTF-8"); response.setHeader("Content-disposition", "attachment;filename=" + fileName + ".xlsx"); EasyExcel.write(response.getOutputStream(), ExportRow.class).sheet("名单").doWrite(rows); }

统计报表我用简单的聚合查询实现，比如按项目统计各院系申请人数，就是一条group by语句配合MyBatis Plus的QueryWrapper。这类报表接口在数据量不大的场景下完全够用，不需要引入额外的报表引擎。把统计结果做成前端ECharts图表展示，视觉效果和专业度都能提升不少，也不需要后端做额外工作。

5. 本地启动、调试部署与常见问题排查

5.1 开发环境准备与启动步骤

拿到源码之后想在本机跑起来，建议按下面的顺序操作，避免环境问题反复折腾。

首先是环境准备，安装JDK 1.8、Maven 3.6+、MySQL 8.0。JDK版本不要装太高，我遇到过直接用JDK 17跑Spring Boot 2.7项目时出现CGLIB代理异常的情况，退回JDK 8就正常了。

然后是初始化数据库。新建fund_system数据库，导入项目里自带的SQL脚本，注意MySQL的时区参数。我之前遇到过一个问题：本地时间比实际时间早了8小时，排查下来是连接串里没有加serverTimezone=Asia/Shanghai，加上之后恢复正常。

接着修改配置文件里的数据库账号密码，执行mvn spring-boot:run或直接启动主类。正常情况控制台会输出Tomcat启动日志和端口号，浏览器访问http://localhost:8080就能看到登录页面。

如果启动时报Consider defining a bean of type 'com.xxx.mapper.xxx' in your configuration，先检查启动类上有没有加@MapperScan注解：

@SpringBootApplication @MapperScan("com.example.fund.mapper") public class FundSystemApplication { public static void main(String[] args) { SpringApplication.run(FundSystemApplication.class, args); } }

5.2 部署时的注意事项

部署到服务器上和本地跑有一点本质区别：数据库连接串、上传目录、端口这些不能在代码里写死，要用配置文件里的外部化参数来管理。

我部署时把配置文件拆成了application.yml和application-prod.yml，生产配置里指定服务器IP和正式数据库连接，本地跑时用默认配置。启动命令带上--spring.profiles.active=prod参数即可切换环境。

还有上传目录问题。本地开发你可能直接写相对路径，但服务器上相对路径取决于启动命令的工作目录，非常容易踩坑。建议配置一个绝对路径，并确保目录有读写权限：

file: upload-dir: /data/fund-system/upload

最后是打包。使用mvn clean package -DskipTests打成可执行jar包后，用nohup java -jar fund-system.jar > app.log 2>&1 &后台启动。日志文件务必保留，后面排查问题全靠它。

5.3 高频问题实录

我把自己实际调试过程中遇到的高频问题整理成一个速查表，这些问题是新手最容易卡住的点。

排查问题的通用思路，我习惯先看日志再猜原因。Spring Boot的报错日志里已经给出了大部分线索，比如SQL异常会带上具体SQL语句，权限不足会提示被哪个拦截器拦截。遇到耗时较长的排查，可以在关键方法入口打一条日志，把入参打出来，能快速确认是前端传参问题还是后端逻辑问题。

还有一个非常实用的调试技巧：在application.yml中配置MyBatis Plus的日志输出。开启logging.level.com.example.fund.mapper=debug之后，控制台会打印所有执行的SQL语句和参数，排查SQL层面的问题效率翻倍。

6. 从这套系统里我提炼出的可复用经验

写完这个项目，我的体会是：做一个Spring Boot管理系统的难点从来不在某个单独的技术点，而在于对业务流程的理解和对数据状态的约束设计。如果业务状态不清晰，代码再怎么写得花哨，最终呈现的效果都是混乱的。

从这个项目里提炼出三个可以复用到其他管理系统的经验。

第一，状态机驱动一切。不管是订单系统、审批系统还是这个奖助学金系统，凡是有多角色、多步骤流程的业务，一定要在数据库设计阶段就把状态枚举定清楚，所有流转只能通过Service层方法触发，不允许直接改库。这个约束能避免大量隐蔽的脏数据问题。

第二，权限控制要提前规划。很多项目开发到一半才开始考虑角色权限，结果把权限判断散落在各个Controller里，后患无穷。像这类管理系统，第一周就应该把角色目录树和权限拦截机制搭好，后面新增业务接口时可以直接沿着已有的角色维度去控制访问。

第三，保留一切操作痕迹。财务类、评审类系统的审计需求特别强，操作日志表越早设计越好。我这次在设计阶段就加入了audit_record表，每次审核、退回、修改都做记录，后期做数据追溯和纠纷处理时省了太多力气。

最后再分享一个小经验：如果你想把这个系统作为毕设向老师展示，建议在答辩前补一个导出PDF或Excel的公示名单功能，并配上按院系统计的柱状图页面。这两个增强点投入成本不高，但视觉呈现和业务完整度会很不一样，评审时容易留下踏实落地的印象。

这套奖助学金管理系统前后我迭代了两个版本，第一版因为表结构设计过度复杂导致编码效率低，第二版简化了表关联、统一了流程状态后才真正跑通全链路。做这类系统，先慢后快才是正确节奏——花足够时间理清业务流程，后面写代码就是顺水推舟的事。