免费源码,从0到1搭建一个公益捐赠管理系统:技术选型、架构设计与核心实现

TECH SHARE

技术干货分享

「公益捐赠管理系统」技术实现方案

全流程闭环•Spring Boot + Vue•全栈开发实践

公益捐赠领域一直存在一个核心痛点：捐赠资金的流向不透明。捐了多少钱、钱花在了哪里、项目进展如何，捐赠者往往无从得知。

基于这个思考，我用Spring Boot + Vue搭建了一个完整的公益捐赠管理系统，实现了从捐赠、审核、使用到公示的全流程闭环。今天把技术方案和核心实现思路分享出来，希望能给正在做类似项目的同学一些参考。

一、技术选型

层级	技术	选择理由
后端框架	Spring Boot 2.7	生态成熟，约定优于配置，快速开发
ORM	MyBatis-Plus 3.4	简化 CRUD，保留 SQL 灵活性
数据库	MySQL 8.0	稳定可靠，社区支持好
前端框架	Vue 2.5	学习曲线平缓，组件化开发
UI 组件库	Element UI 2.3	后台管理系统标配，组件丰富
图表	ECharts 4.x	百度出品，图表类型丰富

选型原则：够用就好。这是一个中小型系统，不需要微服务架构，Spring Boot 单体应用完全够用。前端也不需要上 Vue 3 + TypeScript，Vue 2 + Element UI对于管理后台来说效率更高。

二、系统架构

整体采用经典的前后端分离架构：

浏览器 → Vue2 SPA → HTTP/JSON → Spring Boot API → MyBatis-Plus → MySQL

后端运行在8100 端口，前端开发环境运行在8080 端口，通过 webpack-dev-server 的代理解决跨域。生产环境使用 Nginx 做反向代理，统一入口。

文件上传采用本地存储方案，图片存储在服务器指定目录，通过 Spring 的静态资源映射提供访问。

三、数据库设计

整个系统设计了10 张核心表，我用一张图来展示它们之间的关系：

User ──┬── Record ──── Project ───┬── Plan（项目进度） ├── Collect ──────┘ ├── Usedrecord（资金使用） ├── Dianzan ──────┘ ├── Comment（评论） ├── Score ────────┘ └── Dianzan（点赞） └── Role（角色权限）

几个关键设计决策：

1. 捐赠记录（record 表）

CREATE TABLE record ( id INT PRIMARY KEY AUTO_INCREMENT, type VARCHAR(255), -- "捐款" 或 "捐物" money VARCHAR(255), -- 捐款金额 goods VARCHAR(255), -- 捐物明细 remark VARCHAR(255), -- 备注 uid INT, -- 捐赠者 pid INT, -- 关联项目 status VARCHAR(255), -- "审核中" / "通过" / "拒绝" ctime DATETIME );

支持捐款和捐物两种方式，status 字段实现了审核流程。只有type="捐款"且status="通过"的记录才计入项目可用资金。

2. 资金使用记录（usedrecord 表）

CREATE TABLE usedrecord ( id INT PRIMARY KEY AUTO_INCREMENT, pid INT, -- 关联项目 money VARCHAR(255), -- 使用金额 intro VARCHAR(255), -- 使用说明 ctime DATETIME );

每条记录代表一笔资金支出，关联到具体的公益项目。

3. 角色权限（role 表）

CREATE TABLE role ( name VARCHAR(255), -- 角色名 menu VARCHAR(255) -- 菜单权限 JSON 数组 );

权限设计采用了菜单级别的控制，管理员能看到哪些菜单由 role 表的 menu 字段决定。

四、核心业务实现

4.1 资金监管闭环

这是整个系统最核心的业务逻辑。流程如下：

用户捐赠 → 状态:审核中 → 管理员审核 → 状态:通过/拒绝 ↓ 计入项目可用资金 ↓ 管理员记录资金使用 ↓ 系统校验资金余额 ↓ 公示项目进度

资金校验的核心代码在UsedrecordController中：

// 添加资金使用记录时的校验逻辑 // 1. 计算该项目所有已通过捐赠的总额 // 2. 计算该项目所有已使用资金的总额 // 3. 判断：已用总额 + 本次使用金额 ≤ 已通过捐赠总额 // 4. 不足则返回错误码 -1，提示"可使用资金不足"

这个设计保证了捐赠资金不会被超额使用，每一笔支出都有对应的捐赠来源。

4.2 三级权限体系

系统设计了三个角色：

普通用户（role=1）：只能访问前台页面，进行浏览、捐赠、互动等操作
管理员（role=2）：可以访问后台管理功能，但菜单权限是动态配置的
超级管理员（role=3）：拥有全部权限，包括用户管理和权限分配

管理员的菜单权限存储在 role 表的 menu 字段中，格式为JSON 数组（如[1,2,3,4]）。前端的leftnav.vue组件会根据当前用户的权限列表过滤菜单项，实现动态菜单。

4.3 统计分析仪表盘

后端的ChatController提供了一个聚合接口/chat/list，一次性返回：

{ "pNum": 10, // 公益项目总数 "rNum": "48000", // 已通过捐赠总额 "usedNum": "11000", // 已使用资金总额 "uNum": 14, // 用户总数 "list": [...] // 所有项目及最新进度 }

前端使用ECharts 渲染柱状图（项目进度分布）和饼图（捐赠金额 vs 使用金额），数据一目了然。

五、遇到的问题与改进方向

做这个项目的过程中也发现了一些问题，记录下来作为后续优化方向：

1. 安全问题

密码是明文存储的，应该使用BCrypt 加密
没有Token 认证机制，所有 API 都是裸露的
MyBatis 中使用了${}做 LIKE 查询，存在SQL 注入风险

2. 架构问题

Controller 中直接注入 Mapper，Service 层形同虚设
Controller 使用了实例变量存储分页状态，单例模式下不安全
所有接口都是 POST 方法，RESTful 规范不够严格

3. 可扩展性

文件上传使用本地存储，生产环境应该用 OSS
没有消息通知机制，审核状态变更无法实时推送给用户
没有日志系统，排查问题不方便

这些问题不影响系统的学习价值，但如果要上线使用，建议优先解决安全相关的问题。

六、写在最后

这个项目虽然是一个相对简单的管理系统，但它完整地覆盖了一个 Web 应用的核心要素：

前后端分离架构
用户认证与权限控制
CRUD 业务逻辑
数据校验与业务规则
数据可视化

对于正在学习 Java 全栈开发的同学来说，是一个很好的练手项目。完整源码、数据库脚本和部署文档我都整理好了，需要的可以在评论区留言。

END / 感谢阅读

本文由酷宣AI 排版