基于Spring Boot的企业资金流转管理平台开发实战

一套基于Java的“企业资金流转管理平台”能做多深说白了就是把“钱从哪儿来、花到哪儿去、账上还剩多少”这三件事管明白。很多同学一听到“财务管理系统”就头大觉得要碰一堆复杂的会计科目实际上毕设级别的系统核心反而是把业务流程和数据模型理清楚。这篇博文就从毕设项目的角度把我做这一整套系统的思路、踩坑和可复用的代码细节全部拆出来讲。这个项目适合三类人一是正在选毕设课题、需要一套既有技术含量又能顺畅答辩的Java web系统二是想从零做一个带业务逻辑、不那么“玩具”的Spring Boot练手项目三是工作中要给小团队内部搭建简易资金管理平台不想用太重的SaaS系统。下面所有内容都是我按照“能用、好讲、不过度设计”的标准去组织的读者完全可以照着往下做也可以根据自己的场景增删模块。1. 项目整体设计思路与技术选型1.1 需求到底要做什么标题里的三个关键词“企业资金流转管理”“企业账务收支”“数字化管控系统”翻译成业务语言就是下面这几件事。管好“收支”每一笔收入、支出都有记录谁操作、什么时间、属于什么分类、关联哪个往来单位都得能查到。管好“钱在哪”企业通常有多个资金账户比如基本户、一般户、备用金账户、微信/支付宝收款账户系统要能分别记录每个账户的余额变动。管好“谁经手”员工作为操作员只能按权限使用系统会计负责日常记账老板可以查看报表但不能乱改数据。管好“老板最关心的报表”本月收入多少、支出多少、现金净流入多少、每个账户还剩多少、哪类支出最多这些都是一张统计页就能讲清楚的需求。这四件事对应的就是四类核心功能账务记录、账户管理、用户权限、统计报表。流程上还要加点东西比如“支出需要审核才生效”这样系统的业务闭环就比较完整答辩时也有故事可讲。我见过一些同学把毕设做成纯增删改查两个表就打发了最后答辩时只能硬着头皮演示“我能在页面上增加一条数据”。加一条记录谁都能加能不能讲清楚“为什么这笔钱允许记进来”“这笔钱记进来之后对哪些数据产生了影响”才是拉开差距的地方。1.2 技术栈选型的底层逻辑先给出我这套项目的推荐技术栈再逐个说理由。层次技术选型说明后端框架Spring Boot 2.7.x / 3.x降低配置量快速集成生态成熟持久层MyBatis-Plus分页、条件构造器、逻辑删除开箱即用数据库MySQL 8.x免费、稳定、报表查询常用权限方案Sa-Token 或 手写JWTSa-Token学习成本低手写JWT能讲原理前端Vue 3 Element Plus ECharts界面出效果快图表展现实力导出工具EasyExcel财务系统少不了导出ExcelAlibaba的库很省事为什么选Spring Boot而不是SSH或者Spring MVC因为毕设周期短Spring Boot的自动配置和起步依赖能省掉大量配置文件同时它又是工业界真实在用的技术出了错搜得到答案。MyBatis-Plus则比纯MyBatis省太多事分页不需要手写拦截器单表查询甚至不需要写SQL能把主要精力留在业务设计上。这里补充一个重要建议Java版本不要盲目追新。如果本地安装的是JDK 17甚至21而IDE默认编译级别还是8或者11马上就会遇到经典的“源发行版17需要目标发行版17”报错反过来如果你选了Spring Boot 3.x就要求JDK 17起步这时要确保Maven编译参数、IDEA Project Structure全部对齐。前后端分离方面如果是毕设个人强烈建议用Vue 3 Element Plus做管理端界面因为Element Plus的表格、表单、日期选择器简直是给管理系统量身定制的不用从零写组件样式时间花在业务逻辑上更值。1.3 项目目录结构与核心类规划把项目当成一个将要移交出去的小型产品来组织代码而不是把所有逻辑塞进Controller。下面是我整理的主目录结构按这个写下来代码整洁度会明显高于平均水平。com.example.finance ├── FinanceApplication.java ├── common │ ├── Result.java // 统一返回结果 │ ├── ResultCode.java // 状态码 │ └── exception │ ├── BizException.java │ └── GlobalExceptionHandler.java ├── config │ ├── MybatisPlusConfig.java // 分页插件 │ ├── WebMvcConfig.java // 拦截器、CORS │ └── SaTokenConfig.java // 如果用Sa-Token ├── controller │ ├── AuthController.java // 登录 │ ├── UserController.java │ ├── AccountController.java // 资金账户 │ ├── FlowController.java // 收支流水 │ ├── CategoryController.java // 收支分类 │ ├── SupplierController.java // 往来单位 │ └── ReportController.java // 报表统计 ├── service │ └── impl ├── mapper ├── entity ├── dto ├── vo └── utils ├── JwtUtils.java └── UserContext.java在做这套系统时entity、dto、vo一定要分开这是很多初学者容易混的。Entity对数据库字段一个字段都不能少DTO是接收前端请求参数的可能只有部分字段VO是返回给前端展示的可能额外带“分类名称”“操作人名”这种联表查出来的字段。如果混在一起用后面加一个字段前端就能多传一个字段安全隐患不说代码也越改越乱。2. 数据库设计资金流转这张网怎么织2.1 核心表结构安排资金流转系统有一张最重要的流水表这张表设计得好不好基本决定了整套系统的上限。别急着搞复杂的“双分录”会计结构企业资金流转管理不是做总账系统不需要严格凭证关键在于每一笔钱的流入流出、从哪个账户到哪个账户、关联什么业务。我最终落地的表结构是这样的。用户表sys_userid、username、passwordBCrypt加密、real_name、role_id、status、create_time资金账户表acc_accountid、account_name如“招商银行基本户”、account_no、opening_balance期初余额、current_balance当前余额、status、remark收支分类表acc_categoryid、category_name如“销售收入”“办公耗材”“员工工资”、type1收入2支出、parent_id往来单位表acc_supplierid、supplier_name如“某某科技有限公司”、contact、phone、address、remark收支流水表acc_flow核心表CREATE TABLE acc_flow ( id bigint NOT NULL AUTO_INCREMENT, flow_no varchar(32) NOT NULL COMMENT 流水单号, account_id bigint NOT NULL COMMENT 资金账户ID, category_id bigint NOT NULL COMMENT 收支分类ID, supplier_id bigint DEFAULT NULL COMMENT 往来单位ID, type tinyint NOT NULL COMMENT 1收入 2支出, amount decimal(18,2) NOT NULL COMMENT 金额, business_date date NOT NULL COMMENT 业务日期, occur_time datetime NOT NULL COMMENT 实际发生时间, status tinyint NOT NULL DEFAULT 0 COMMENT 0待审核 1已通过 2已驳回, audit_by bigint DEFAULT NULL COMMENT 审核人, audit_time datetime DEFAULT NULL COMMENT 审核时间, create_by bigint DEFAULT NULL COMMENT 创建人, create_time datetime NOT NULL, remark varchar(255) DEFAULT NULL, is_deleted tinyint NOT NULL DEFAULT 0, PRIMARY KEY (id), KEY idx_account_business_date (account_id, business_date), KEY idx_type_status (type, status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这张表上有几个细节值得讲。金额字段用decimal(18,2)绝对不能设成float或者double199.99这种数在二进制里存不准求和多了就会有一分钱对不上的老问题。流水单号单独一列不用数据库自增id来顶替因为流水的单号包含业务信息比如预处理成“LZ20250317001”这样可读性很强的编号。2.2 余额一致性问题怎么处理“当前余额”存进表里听起来简单做起来有坑。假设账户表里 current_balance 10000现在审核通过了一笔 2000 的支出你可能会这么写account.setCurrentBalance(account.getCurrentBalance() - 2000);两个问题随之而来。第一个并发场景下两个人同时读余额都是10000都减2000最后余额就变成了8000而不是6000这就产生了资金数据不一致第二个如果没有事务控制扣减余额成功之后更新流水状态失败钱就凭空少了一截。我这里用的方案是账户余额的扣减只在“审核通过”这个动作发生时才执行并且用带条件的更新语句来做兜底。Transactional(rollbackFor Exception.class) public void auditPass(Long flowId) { AccFlow flow flowMapper.selectById(flowId); if (flow null || flow.getStatus() ! 0) { throw new BizException(流水不存在或状态已变更); } // 判断账户余额是否足够支出场景 if (flow.getType() 2) { Account account accountMapper.selectById(flow.getAccountId()); if (account.getCurrentBalance().compareTo(flow.getAmount()) 0) { throw new BizException(账户余额不足无法通过审核); } } // 原子化更新余额 if (flow.getType() 1) { accountMapper.plusBalance(flow.getAccountId(), flow.getAmount()); } else { accountMapper.minusBalance(flow.getAccountId(), flow.getAmount()); } // 更新流水状态 flowMapper.updateStatus(flowId, 1, currentUserId, new Date()); }这里最关键的思路是流水只负责记录账户余额只由审核动作触发创建流水时不改余额。这样设计的好处是你随时可以反查“这笔余额到底是怎么变动的”每一分钱变动都有对应的流水凭证。要做反查也很简单按账户查流水表时间倒序排列就是一个完整资金流水账单。2.3 金额计算与精度处理财务系统写业务代码时第一个必须养成的好习惯就是凡是金额一律用BigDecimal加法用add减法用subtract乘法用multiply除法用divide并设置精度比如divide(divisor, 2, RoundingMode.HALF_UP)。我见过有人图省事在代码里这么写BigDecimal result new BigDecimal(0.1) .add(new BigDecimal(0.2));这样没问题输出是0.3但一旦换一种写法BigDecimal result new BigDecimal(0.1) .add(new BigDecimal(0.2));结果就变成了0.30000000000000004这是因为new BigDecimal(double)会把二进制浮点数的不精确值原封不动搬过来。所以项目里我做了统一约束从第三方接口、数据库、前端JSON过来的金额都优先用字符串构造BigDecimal前端传数值型时也不做隐式转换统一转字符串再处理。这个细节写进代码规范里能帮你规避掉很多“账对不上”的问题。另外还要注意前端展示。金额别直接打印10000.0这种格式用DecimalFormat或者NumberFormat转成用户熟悉的格式。在Vue项目里可以在表格列上加一个formatter保留两位小数并千分位展示这样“今天账上进了多少钱”一眼就能看明白给老师演示也干净。3. 后端核心业务模块实现与关键代码3.1 登录认证与权限控制权限设计上我见过最低成本且能讲清楚逻辑的方案用户表放角色角色分管理员/财务/普通员工后端用拦截器校验是否登录再用方法级注解校验角色。如果不想引入太重的Spring Security建议用Sa-Token它比手写JWT省心不少。但为了答辩能讲清楚“我是怎么实现登录认证的”我建议核心逻辑自己写一层。比如用JWT登录接口校验用户名密码通过后生成一个token返回给前端前端请求时放到Header里拦截器统一解析。要做到能控制接口权限可以在自定义注解里声明所需角色Target({ElementType.METHOD, ElementType.TYPE}) Retention(RetentionPolicy.RUNTIME) public interface RequireRole { String[] value(); }拦截器里读取token中的用户信息再查一次数据库拿到当前用户角色和注解声明的角色做比对不匹配就抛401。这里有一个值得注意的开发习惯不要把角色直接拼在JWT里就不管了因为角色可能被修改拦截器每次查库虽然多消耗一次IO但在这种小型系统里完全可接受换来的是权限变更即时生效。密码存储只用MD5是很多新手项目的老毛病MD5算出来的哈希值很容易被彩虹表匹配出来。我采用了BCrypt加密Spring Security里自带的BCryptPasswordEncoder可以直接单独拿来用即使两个用户密码相同哈希值也不同安全性上一个档次。3.2 记账业务的完整链路记账是平台的核心动作。用户从前端填写一笔收入先进入待审核状态审核通过后才真正影响账户余额这是面向“企业资金管控”这个场景特意设计的流程。一个传统的个人记账App可以一提交就生效但企业里钱花出去之前需要有人确认这笔钱该不该花、发票齐不齐。实现这条链路前端提交流水表单时后端要做四件事校验参数金额必须大于0账户/分类必须存在业务日期不能为空。生成流水单号日期 类型 当天自增序号。保存流水status默认待审核此时不改账户余额。记录创建人和发生时间为后续追踪留底。下面这段是流水单号生成的参考实现public String generateFlowNo(Integer type, Date date) { String dateStr DateUtil.format(date, yyyyMMdd); // 当天该类型已有多少条 Long count flowMapper.countByTypeAndDate(type, dateStr); return LZ dateStr (type 1 ? S : Z) String.format(%04d, count 1); }这里需要注意并发问题如果同时生成两个单号count相同会导致单号冲突。小场景下可以用“乐观锁/唯一索引”兜底更稳妥的做法是用数据库序列或者Redis自增但毕设的话在service层代码里加synchronized虽然不优雅也是能应付到几千条数据的。我实际项目里是把单号生成放进了一个独立的短事务并使用数据库唯一索引字段兜底如果插入冲突就让用户重试一次实际很少发生。3.3 资金流水查询与报表统计资金流水的列表查询通常是个多条件组合查询条件包括时间范围、账户、收支类型、分类、状态、关键字。用MyBatis-Plus的条件构造器写起来非常自然public PageAccFlowVO pageFlow(FlowQueryDTO dto) { LambdaQueryWrapperAccFlow wrapper Wrappers.lambdaQuery(); wrapper.eq(dto.getAccountId() ! null, AccFlow::getAccountId, dto.getAccountId()) .eq(dto.getType() ! null, AccFlow::getType, dto.getType()) .eq(dto.getStatus() ! null, AccFlow::getStatus, dto.getStatus()) .between(dto.getStartDate() ! null dto.getEndDate() ! null, AccFlow::getBusinessDate, dto.getStartDate(), dto.getEndDate()) .like(StringUtils.isNotBlank(dto.getRemark()), AccFlow::getRemark, dto.getRemark()) .orderByDesc(AccFlow::getBusinessDate) .orderByDesc(AccFlow::getCreateTime); return flowMapper.selectPage(new Page(dto.getPageNum(), dto.getPageSize()), wrapper); }不要小看这个查询接口它是整个系统里使用频率最高的一个也是面试时最容易被追问的。老师很可能问“如果流水表到了几百万条查询变慢怎么办”这时候你可以回答按业务日期建索引、查询条件组合排序已经覆盖了索引、必要时可以按年拆表/按账户拆表或者引入Elasticsearch。就算没真的做能把方案讲有条理也会给答辩加分。报表模块是另一个大项。老板关心的“本月收入支出”怎么算答案是用SQL聚合select idsumByMonth resultTypecom.example.finance.vo.SumVO SELECT DATE_FORMAT(business_date, %Y-%m) AS month, type, SUM(amount) AS totalAmount FROM acc_flow WHERE status 1 AND is_deleted 0 AND business_date gt; #{startDate} AND business_date lt; #{endDate} GROUP BY DATE_FORMAT(business_date, %Y-%m), type /select日期范围用传入参数而不是写死在SQL里这样前端时间选择器自由度很大。有了月维度汇总以后再用ECharts画折线图展示“近6个月收入支出趋势”一眼就能看出这个企业现金流是向好还是吃紧这也是答辩亮点。为了报表再完整一些我建议额外提供“账户余额汇总”接口把每个账户当前的余额列出来以及“分类支出占比”接口明确告诉老板钱主要花在哪个科目上。这些数据都从acc_flow表按条件聚合得到不需要额外建表实现成本很低收益却很大。3.4 导出Excel的实现方式财务系统不带Excel导出用户必然吐槽“还得手动整理报表”。排版上我选择的是后端用EasyExcel生成文件流前端trigger一个下载链接。public void exportFlow(FlowQueryDTO dto, HttpServletResponse response) throws IOException { ListAccFlow list flowMapper.selectList(buildQuery(dto)); ListFlowExcelRow rows list.stream().map(item - { FlowExcelRow row new FlowExcelRow(); BeanUtils.copyProperties(item, row); return row; }).collect(Collectors.toList()); response.setContentType(application/vnd.openxmlformats-officedocument.spreadsheetml.sheet); response.setCharacterEncoding(utf-8); String fileName URLEncoder.encode(资金流水_ System.currentTimeMillis(), UTF-8); response.setHeader(Content-disposition, attachment;filename fileName .xlsx); EasyExcel.write(response.getOutputStream(), FlowExcelRow.class) .sheet(资金流水) .doWrite(rows); }EasyExcel最省力的地方在于不需要在代码里逐行摆样式用注解定义好字段和表头就行。这里需要留意的是导出文件名称如果带有中文必须做URL编码否则浏览器下载下来往往是乱码文件名。另外后台导出的数据量如果很大不要一次性查全表可以分页查询循环写入防止内存溢出。4. 前端页面搭建与交互数据流4.1 页面骨架与路由设计管理系统前端我用的是Vue3 Vite Element Plus。从效率角度来看Vue全家桶的脚手架速度、热更新体验都要远好于传统JSP。页面规划上我按导航菜单拆成了五个主要页面工作台/仪表盘放账户余额卡片、月度收支趋势图、待审核数量提醒。资金账户账户列表新建账户、余额查看、账户流水入口。收支流水查询条件区 表格 新增/审核/驳回操作。基础资料收支分类管理、往来单位管理。数据报表收入支出趋势、分类占比、导出Excel入口。路由懒加载不要省管理端的页面互相独立按需加载后首屏速度肉眼可见地提升。侧边栏菜单可以本地写死也可以从后端根据用户角色动态返回毕设建议从后端动态返回这样“权限控制”就能直观展示出来——老板登录看到的菜单和财务登录看到的不一样。4.2 表单校验与金额输入的细节前端最容易翻车的就是金额输入。用户在页面上既可以输入整数也可能输入逗号分隔的数字、带货币符号的数字。我统一用el-input-number并设置:precision2和:step0.01同时把值的类型设成number。有一点要提醒Element Plus的el-input-number在极小数时会有浮点数精度展示问题你可以在change回调里转成字符串后只保留两位再存。日期选择器也值得优化。比如“业务日期”的默认值直接给当天不仅减少用户操作也更能模拟日常记账的习惯数据演示的时候节奏会更快。审核弹窗内的“审核意见”字段非必填但状态改变后必须回显在流水表格的“状态”列用户得知道他这单是被谁批准了。4.3 可视化图表与数据刷新策略ECharts在Vue项目里可以封装一个通用图表组件。我的做法是封装一个BaseChart.vue接收option作为propswatch变化后setOption避免在页面组件里重复写一堆初始化逻辑。饼图和折线图的数据由首页的接口一次性返回后端设计一个聚合VOpublic class DashboardVO { private ListAccountVO accountList; private ListTrendVO trendList; private MapString, BigDecimal categoryAmountMap; private Long pendingAuditCount; }这样一个接口就能渲染整个仪表盘。页面加载时调一次切换账户数据后刷新一次。这里有个开发体验上的建议图表加载过程中一定要加真实Loading状态不要让图表区域白花花一片。财务系统数据量不大不需要Redis缓存但可以为“近6个月趋势”“账户汇总”这类固定聚合加一个Controller层的本地缓存过期时间设5分钟能有效减少MySQL的聚合计算压力。5. 部署、答辩与常见问题排障5.1 环境准备与打包部署技术栈确认以后开发机上的环境要尽量和生产保持一致。我本地的组合是JDK 1.8或17看框架版本、Maven 3.8、MySQL 8.0、Node 16。开发完以后打包后端用mvn clean package前端用npm run build然后把前端dist目录下的静态文件交给Nginx托管后端jar包用java -jar直接启动通过Nginx反向代理/api路径到后端端口这样整个简历里可以写“前后端分离部署”。如果你不想折腾Nginx也可以直接用Spring Boot把前端静态资源一起打包成一个jar。做法是把前端构建后的dist目录内容复制到src/main/resources/static然后再重新打包这样浏览器直接访问后端8080端口就能看到页面。这种单jar部署在毕设答辩时特别方便一个命令跑起来不会因为环境问题当场翻车。5.2 答辩演示脚本建议当老师坐在屏幕前你不会想临时去想“第一步做什么”。我建议按下面这个顺序演示登录之后先进工作台让老师看到账户余额、待审核提醒、趋势图先建立“这是一个完整系统”的观感。然后点进“资金账户”新建一个账户初期余额10000这里讲一个设计点期初余额与当前余额是分开的能够准确反映账户历史。接着去“收支流水”提交一笔销售收入2000元演示“提交后状态是待审核”再提交一笔办公采购支出500元然后进入审核流程点击通过回工作台看到余额相应变化说明“流水的审核驱动了余额变动”。最后进入“数据报表”导出Excel打开文件给老师看一眼。整条路走完不到五分钟但把登录、权限、账户、流水、审核、余额、报表、导出全串了起来。答辩时老师最爱问“这个表的余额是怎么保证正确的”“并发重复提交怎么防止”。我在写代码时就把这些想明白了状态流转有前置校验带注解枚举校验账户余额不直接暴露给Controller层修改只在service内部通过调用Mapper的原子SQL更新创建流水前检查账户是否有禁用状态避免向禁用账户里记钱。有了这些细节回答类似问题时都能做到有据可依。5.3 新手常见报错速查表这里整理了我在搭建和运行过程中最容易遇到的几类问题每一条都遇到、解决过。问题现象根本原因解决方式编译报错“源发行版17需要目标发行版17”IDE编译级别与JDK版本不一致Maven的maven-compiler-plugin和IDEA Project Structure统一source/target为17中文乱码页面显示问号MySQL连接URL未指定UTF-8连接串加characterEncodingutf8建库时选utf8mb4decimal精度丢失少一分钱使用了BigDecimal.doubleValue或float参与计算金额统一用BigDecimal除法指定精度跨域报错前端请求不到接口前后端分离未处理CORS后端配置CorsFilter或WebMvcConfigurer生产环境用Nginx同源代理事务注解不生效方法被同类内部调用或者没有走代理事务方法放在service由Controller注入调用不要在同类内部自调用点击导出没有反应下载请求被拦截或者后端异常给下载接口放行登录校验前端用window.open或a标签触发最后再补充一个容易忽略的点所有流水表、账户表都要加is_deleted逻辑删除字段千万别用物理删除。财务系统里任何一条记录原则上都只能作废不能消失。一旦真删了后来审计流水的时候资金变动链条就断了查都查不回来。MyBatis-Plus里只需在实体字段上标TableLogic删除就会自动变成更新is_deleted字段查询时也不会带出已删除数据成本极低好处极大。6. 这个项目还能怎么扩展做完整套系统以后我对“企业资金流转管理平台”这个题目的理解比刚开题时清晰了很多。财务管理系统的难点不在写代码而在数据模型和业务规则的严谨性。账上每一笔钱的变动都有迹可循每个用户的动作都留下可审计的记录这才是“数字化管控”四个字的底气所在。从扩展性角度来说如果以后想更贴近真实企业可以再往下面几个方向补一是对接银行流水导入通过Excel批量导入功能把线下账单拉上线二是增加预算管理每个分类设月度预算超支自动预警三是引入简单的审批流比如超过一定金额的支出需要多级审批。这些都建立在当前这套数据模型之上说明底层设计留了足够余地。做这个项目时最实际的收获是什么其实是在修bug的过程中慢慢把“并发”“事务”“审计”“状态流转”这些平时只停留在八股文里的概念真正用到了代码里。面试时我可以对着项目讲清楚“为什么审核通过和余额扣减必须在一个事务里”“为什么流水表要按业务日期建索引”而不是只背一段概念。如果你也在做类似的毕设或者练手项目我建议把精力重点放在这三个环节数据表设计、资金流水审核链路、报表聚合查询把它们打磨好整套系统的骨架自然就立住了。