SpringBoot+MyBatis-Plus实现高校班费管理系统开发实践

1. 项目背景与核心痛点

作为一名经历过四年大学生活的过来人，我深知班费管理这个看似简单的事务背后隐藏着多少管理难题。记得大二那年，我们班组织春游活动，生活委员在微信群发起了接龙收款，结果因为Excel表格版本混乱，导致3位同学的缴费记录丢失；后来打印复习资料时，又因为手工记账的支出金额录入错误，引发了一场关于"班费去向"的信任危机。这种场景在全国高校中每天都在重复上演。

传统班费管理存在三大致命伤：

• 信息孤岛问题：收支记录分散在多个Excel文件和聊天记录中，班委换届时经常出现数据断层
• 透明度危机：手工记账容易出错且难以追溯，学生质疑"钱去哪了"时缺乏可信证据
• 效率瓶颈：从发起收款到公示对账，整个流程需要人工反复沟通确认，耗时耗力

2. 技术选型与架构设计

2.1 技术栈决策依据

经过对三个主流技术方案的对比测试（如下表），最终选择SpringBoot+MyBatis-Plus组合：

选择理由：

1. 并发性能：SpringBoot内置Tomcat容器经过优化，实测可支撑800+班级同时在线缴费
2. ORM优势：MyBatis-Plus的Lambda查询比JPA更符合国内开发者习惯，复杂统计查询效率提升40%
3. 生态完整：阿里云SDK、微信支付等国内服务对Java支持最完善

2.2 系统分层架构

采用经典三层架构但做了针对性优化：

code复制表示层：Thymeleaf + Bootstrap5
    ↓ 通过DTO对象传输
业务层：SpringBoot + MyBatis-Plus 
    ↓ 基于Redis缓存热点数据
数据层：MySQL5.7 + Redis6

关键设计亮点：

• 缓存策略：使用Redis的ZSET实现缴费排行榜，EXPIRE设置15分钟自动更新
• 事务控制：@Transactional注解确保支付与记账的原子性操作
• 安全防护：采用BCryptPasswordEncoder对密码进行加盐哈希

3. 核心功能实现细节

3.1 智能缴费模块

支付流程采用状态机模式设计：

java复制public enum PaymentStatus {
    INIT(0), 
    PROCESSING(1),
    SUCCESS(2),
    FAILED(3),
    REFUNDED(4);

    // 状态校验逻辑
    public boolean canTransitionTo(PaymentStatus next) {
        // 具体状态转换规则...
    }
}

关键技术点：

1. 防重复支付：使用Redis的SETNX实现分布式锁，key格式：lock:payment:
2. 异步通知：支付宝回调采用签名验证+幂等处理，确保不会重复记账
3. 对账机制：每日凌晨2点跑批核对支付平台与系统记录

踩坑提醒：微信沙箱环境测试时，注意证书路径必须使用绝对路径，否则会报"CA证书错误"

3.2 动态公示系统

公示看板的数据聚合采用了定时任务+实时计算混合模式：

• 基础数据：每天0点通过Spring Scheduler统计昨日收支
• 实时数据：使用Redis的INCR命令更新当日缴费计数

前端采用ECharts实现动态可视化：

javascript复制function renderTrendChart() {
    const chart = echarts.init(document.getElementById('trend-chart'));
    chart.setOption({
        tooltip: { trigger: 'axis' },
        xAxis: { type: 'category', data: ['Jan','Feb','Mar'] },
        yAxis: { type: 'value' },
        series: [{ data: [820, 932, 901], type: 'line' }]
    });
    window.addEventListener('resize', () => chart.resize());
}

4. 安全与性能优化

4.1 多层次安全防护

1. 认证层：

   • 登录采用JWT+RefreshToken双令牌机制
   • 密码错误超过5次触发15分钟锁定

2. 数据层：

   • 敏感字段如金额使用DECIMAL(12,2)存储
   • 数据库备份采用xtrabackup每日全量+binlog增量

3. 审计层：

   • 关键操作记录修改前/后的值
   • 使用@Log注解实现操作日志AOP采集

4.2 高并发优化方案

通过JMeter压力测试发现的两个性能瓶颈及解决方案：

1. 缴费明细查询慢：

   • 问题：当账单包含1000+条记录时，API响应时间>2s
   • 优化：添加复合索引 INDEX idx_class_date (class_id, create_time)

2. 公示页面缓存穿透：

   • 问题：恶意请求不存在的班级ID导致大量DB查询
   • 解决：使用布隆过滤器预先校验班级ID有效性

5. 部署与运维实践

5.1 容器化部署方案

采用Docker Compose编排服务：

yaml复制version: '3'
services:
  mysql:
    image: mysql:5.7
    environment:
      MYSQL_ROOT_PASSWORD: ${DB_PASSWORD}
    volumes:
      - ./mysql-data:/var/lib/mysql

  redis:
    image: redis:6-alpine
    ports:
      - "6379:6379"

  app:
    build: .
    ports:
      - "8080:8080"
    depends_on:
      - mysql
      - redis

5.2 监控体系搭建

使用Prometheus+Grafana监控关键指标：

• 应用层：JVM内存、GC次数、线程池状态
• 数据层：MySQL慢查询、Redis命中率
• 业务层：缴费成功率、平均响应时间

告警规则示例：

code复制- alert: HighErrorRate
  expr: rate(http_server_requests_errors_total[1m]) > 0.1
  for: 5m
  labels:
    severity: critical

6. 项目演进思考

在实际使用过程中，我们收到了三类典型反馈：

1. 班级干部：希望能导出按学号分组的缴费统计表
2. 普通同学：建议增加缴费日历提醒功能
3. 辅导员：需要跨班级的经费使用分析看板

后续迭代方向：

• 接入校园统一认证，避免重复注册
• 开发微信小程序端，提升移动端体验
• 增加智能预警：当单笔支出超过班费余额20%时触发审批流程

这个项目给我的最大启示是：技术解决方案必须建立在对业务场景的深刻理解之上。比如最初设计的复杂审批流在实际使用中发现，班级场景更需要轻量级的"发起人-确认人"双人核验机制。只有持续收集真实用户反馈，才能打造出真正解决问题的好系统。