简介基于Java技术的金融信贷系统设计源码包聚焦信贷业务处理场景可供金融机构、信贷系统开发人员及Java学习者参考学习。项目按Maven标准组织包含管理后台、客户端及银行接口等模块整体采用B/S架构与Spring/MyBatis等主流框架覆盖客户管理、信贷产品、审批流程、合同与风险管理等核心业务逻辑。包内共85个文件以27个XML配置、27个Java源文件、27个Class文件为主另含2个YAML配置、1个Git忽略文件及说明文档压缩包大小约139KB。XML与YAML用于框架集成与运行配置Java源码与Class文件对应业务实现与编译产物结构清晰。目前已有313人学习下载适合作为金融信贷系统从设计到实现的入门参考。通过阅读源码可理解工程模块划分、接口交互方式及数据库相关配置为二次开发或毕业设计提供范本。1. 基于Java技术的金融信贷系统设计源码它到底在解决什么问题在码云、CSDN和各类毕设平台上「基于Java技术的金融信贷系统设计源码」是一个出现频率非常高的标题点进去大多是课程设计、毕业设计或者面试前的练手项目。一个做信贷系统的Java后端核心并不是“能有多高的并发”而是进件、审批、授信、放款、还款、逾期这一整条资金链路算得准、理得清。只要你在做账务相关的系统哪怕只是一个几千行的单体工程也要把额度、借据、还款计划这三类核心对象设计到位。这篇内容会沿着一条最小可跑的路径展开先确定技术选型和工程结构再设计支撑信贷业务的表结构然后落地放款审批、还款计划生成等关键代码最后把让新手最容易翻车的细节挑出来讲透。适合打算用Java走通信贷系统全流程的人也适合准备面试时把“额度扣减、等额本息、提前还款”这些账务概念讲明白的人。2. 技术选型与工程结构为什么Spring Boot MyBatis-Plus是信贷源码的地基2.1 信贷系统的核心是账务准确不是并发微服务在这里是负资产信贷系统和秒杀系统不一样。秒杀要压的是 TPS信贷要压的是“每一笔钱都必须对得上账”。哪怕你今天只放了一万笔贷款到了结算日有一笔还款计划差了一分钱后面的对账流程就会卡住。很多人在课设阶段就急着上 Spring Cloud、拆微服务、搞消息队列结果事务被拆得稀碎一个放款动作跨三个服务最终一致性问题远比自己想的难处理。常见做法是单体 模块化工程内部把customer客户、credit授信、loan借据、repayment还款拆成独立 package。选 Spring Boot 而不是别的框架理由也很直接Java 后端的主流岗位要求里Spring Boot 是默认底线只要你会 Spring Boot再去看 SSH、Play、Vert.x 这些方案心智成本完全不同。选 MyBatis-Plus 而不是 JPA 或 MyBatis 原生更大程度是效率问题。信贷系统有大量单表 CRUDMyBatis-Plus 的BaseMapper直接省掉 mapper XML它的乐观锁插件、字段自动填充、分页插件都是现成的。相比 JPAMyBatis-Plus 会让新人更容易理解 SQL 和数据表本身查问题时可以顺手把 SQL 拉出来看。在 Spring Boot 2.7.x / 3.x 搭配 MySQL 8.0 这个组合下MyBatis-Plus 3.5.x 是当前工程化最顺手的版本。提示如果你准备拿这套系统去面试或做毕设一定要能把“为什么不用微服务”讲透而不是只会跟着教程写注解。2.2 三个领域模型决定表结构客户、额度与借据信贷系统再复杂底层始终围绕几个固定对象运转。客户Customer是最基本的主体一个人在一个平台只能有一个客户号身份证、手机号、学历、职业等信息都属于客户维度。额度CreditLimit/Quota是客户可借款的上限它和借据是分开的额度是“能借多少”借据是“实际借了多少”。借据Loan是一笔已经放款成功的借款它关联客户、合同编号、放款金额、利率、期数、还款方式。把这三个模型拆开是信贷系统设计里的一条铁律。很多人做毕设时把“额度”字段直接写在客户表里放款时去改客户表的余额最后算账算不清。额度必须是一个独立实体它记录总额度、已用额度、可用额度每次放款时从“可用额度”里扣减每次还款时还回部分额度。这样做的好处是后续接营销活动临时额度、固定额度调整时不用改客户表结构。2.3 建立一个最小可启动的工程骨架依赖清单与分层结构以下是一个可直接照抄的单模块 Maven 工程骨架我平时做信贷类小工程也这么起手dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3/version /dependency dependency groupIdcom.mysql/groupId artifactIdmysql-connector-j/artifactId scoperuntime/scope /dependency dependency groupIdorg.projectlombok/groupId artifactIdlombok/artifactId optionaltrue/optional /dependency /dependencies这里有个细节值得注意MySQL 8 之后必须用mysql-connector-j老的mysql-connector-java坐标虽然还能解析但在 Spring Boot 2.7.x 里会有运行时警告到 Spring Boot 3.x 直接加载不到驱动。MyBatis-Plus 的版本建议直接用你本地 Spring Boot 对应的大版本不要追求最新稳定第一。分层结构上常见的做法是这样src/main/java/com/example/credit/ ├── CreditApplication.java -- 启动类 ├── common/ -- 统一返回体、异常处理 ├── config/ -- MyBatis-Plus 配置、乐观锁插件 ├── controller/ -- REST 接口层 ├── service/ -- 业务逻辑层放款/还款/审批 ├── entity/ -- 数据库实体对应业务表 ├── mapper/ -- MyBatis-Plus 的 Mapper 接口 └── util/ -- 金额计算、利率换算等工具Controller 层只负责接收参数和返回结果不应该写任何业务计算放款、生成还款计划这类账务操作必须放在 Service 层并且加上Transactional。把计算逻辑写到 Controller 里是课设代码最常见的坏味道一旦后期加一个批量放款接口代码就只能复制粘贴。3. 五张核心表与自动建表工具从 Java 实体到 DDL3.1 客户表与授信额度表把“能借多少”和“借给谁”拆开建表是整个系统里最不能省步骤的环节。很多人喜欢直接用 Navicat 或命令敲 DDL但如果团队里多人协作字段类型、注释风格都不一样后面统一风格非常痛苦。常见做法是先定义 Java 实体再用工具从实体类生成建表 SQL保证字段名、注释和类型都跟着实体走。客户表主要字段设计如下字段名类型说明idbigint客户编号主键customer_novarchar(32)客户号业务唯一标识id_card_novarchar(64)身份证号密文存储real_namevarchar(64)客户姓名mobilevarchar(20)手机号credit_levelvarchar(10)信用等级A/B/C/Dstatustinyint状态0 禁止 / 1 正常授信额度表把“能借多少”和“借给谁”拆开。得到客户表后额度表才有意义。一个客户可能有多条额度记录平台固定额度和活动临时额度要分开记账但对外展示时合并成一个“可用额度”。额度表关键字段是总额度、已用额度、状态和版本号字段名类型说明idbigint主键customer_novarchar(32)客户号total_amountdecimal(18,2)总额度used_amountdecimal(18,2)已用额度available_amountdecimal(18,2)可用额度可冗余versionint乐观锁版本号available_amount实际上可以不落库用total_amount - used_amount算出来。我建议保留这个字段但是把计算和写入统一交给额度服务而不是在业务代码里随意更新否则很容易出现总额度连续扣减两次的严重故障。3.2 借据表、还款计划表与交易流水表放款与还款的账务闭环借据loan表记录每一笔实际放款。这里的关键是借据是账务事实一旦生成不能修改本金和利率。提前还款、展期都通过追加交易流水来处理而不是回头去改借据字段。字段名类型说明idbigint主键loan_novarchar(64)借据号customer_novarchar(32)客户号contract_novarchar(64)合同号principaldecimal(18,2)放款本金annual_ratedecimal(8,6)年利率如 0.072000loan_termint期数repay_typevarchar(10)还款方式DEBX / XXHBstatusvarchar(10)状态已放款/已结清/已逾期还款计划repayment_plan表是信贷系统最容易出差错的地方。每笔借据会按“等额本息”或“先息后本”生成 N 期还款计划包含每期应还本金、应还利息、应还总额和剩余本金。这张表是后续还款、对账、逾期的直接依据必须在放款成功瞬间一次性生成不能靠前端计算再回传。生成还款计划后每一笔还款动作都应该写交易流水trade_flow用于记录“什么时间、还了哪一期、本金多少、利息多少”然后通过流水去更新还款计划状态。这套“借据—计划—流水”的闭环是账务系统不会乱的基础。3.3 用 MyBatis-Plus 实体反向生成建表 SQL类型映射与参数说明下面直接写一个简单的 DDL 生成器原理是用反射读取实体类的字段再按 Java 类型映射到 MySQL 类型。这套做法不依赖 MyBatis-Plus 的内部 API就算升级版本也不会炸是更稳的方案。public class DdlGenerator { public static String generateCreateTableSql(Class? entityClass) { StringBuilder sb new StringBuilder(); TableName tableName entityClass.getAnnotation(TableName.class); sb.append(CREATE TABLE IF NOT EXISTS ) .append(tableName.value()) .append( (\n); Field[] fields entityClass.getDeclaredFields(); for (Field field : fields) { if (Modifier.isStatic(field.getModifiers())) { continue; } sb.append( ) .append(resolveColumnName(field)) .append( ) .append(mapJavaTypeToMysql(field.getType())); if (field.isAnnotationPresent(TableId.class)) { sb.append( PRIMARY KEY AUTO_INCREMENT); } else { sb.append( DEFAULT NULL); } sb.append(,\n); } sb.delete(sb.length() - 2, sb.length()); sb.append(\n) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT) .append(tableName.value()) .append(;\n); return sb.toString(); } private static String mapJavaTypeToMysql(Class? type) { if (type Long.class || type long.class) return bigint; if (type Integer.class || type int.class) return int; if (type BigDecimal.class) return decimal(18,2); if (type LocalDateTime.class || type Date.class) return datetime; if (type String.class) return varchar(64); return varchar(255); } }这段生成器里TableName指定表名TableId标记主键字段普通字段按类型映射。varchar(64)对手机号、身份证这种固定长度的业务编号够用但像合同号这种可能带特殊前缀加时间戳的字段建议手动在注解里扩展成varchar(128)。类型映射表里唯一需要校准的是BigDecimal数据库层面必须用decimal(18,2)不要用 float/double否则审计的时候算账本对不上就是血泪经验。提示这个生成器只适合表结构简单、主键自增的存量表。对已有线上数据表做变更时还是要用 Flyway 这类版本化迁移工具不要直接在实体上改字段然后重新生成一遍。4. 信贷主流程代码实现进件审批、放款与还款计划生成4.1 自动审批规则额度、年龄与黑名单的三层判断信贷系统里自动审批是最能直观体现业务逻辑的模块。这里我省略掉反欺诈、人工审批工作流这类重模块讲一个三层的规则决策第一层是黑名单校验第二层是客户基本准入校验年龄、职业、实名状态第三层是额度校验。任何一层不通过直接终止并返回拒绝原因。Service public class CreditDecisionService { public DecisionResult approve(ApplyRequest req) { // 1. 黑名单校验 Customer customer customerMapper.selectByCustomerNo(req.getCustomerNo()); if (customer null || customer.getStatus() 0) { return DecisionResult.reject(客户不存在或已禁用); } // 2. 年龄校验 int age Period.between(customer.getBirthDate(), LocalDate.now()).getYears(); if (age 22 || age 60) { return DecisionResult.reject(年龄不在准入范围22-60岁); } // 3. 额度校验 CreditLimit limit creditLimitMapper.selectByCustomerNo(req.getCustomerNo()); if (req.getAmount().compareTo(limit.getAvailableAmount()) 0) { return DecisionResult.reject(申请金额超过可用额度); } return DecisionResult.pass(审批通过); } }决策顺序有讲究黑名单和年龄这类硬性条件要在额度校验之前因为额度查询通常要锁行或走 Redis代价更高。DecisionResult里除了 pass/reject建议带一个reasonCode枚举后续给前端展示“拒绝原因详情”时用得上。千万别在整个审批流程里只返回一个布尔值那样用户被拒了根本不知道是哪一环卡住。4.2 等额本息与先息后本用 BigDecimal 写一份不会翻车的还款计划生成器信贷系统里最有技术含量的地方是还款计划生成。等额本息公式是月利率 r 年利率 / 12每期还款额 M 本金 × r × (1 r)^n / ((1 r)^n - 1)这里必须强调金额计算一律用BigDecimal不允许出现double。用 double 算 36 期之后本金利息对不上是必然的。下面是一份可以直接复用的生成器public class RepaymentPlanGenerator { public static ListRepaymentPlan generateEqualInstallment( BigDecimal principal, BigDecimal annualRate, int terms) { BigDecimal monthlyRate annualRate .divide(BigDecimal.valueOf(12), 10, RoundingMode.HALF_UP); BigDecimal onePlusRate BigDecimal.ONE.add(monthlyRate); // 计算 (1r)^n用循环乘法避免 Math.pow 的 double 误差 BigDecimal pow BigDecimal.ONE; for (int i 0; i terms; i) { pow pow.multiply(onePlusRate); } // M P * r * (1r)^n / ((1r)^n - 1) BigDecimal monthPay principal .multiply(monthlyRate) .multiply(pow) .divide(pow.subtract(BigDecimal.ONE), 2, RoundingMode.HALF_UP); BigDecimal remainPrincipal principal; ListRepaymentPlan plans new ArrayList(); for (int i 1; i terms; i) { BigDecimal interest remainPrincipal .multiply(monthlyRate) .setScale(2, RoundingMode.HALF_UP); BigDecimal principalPart monthPay.subtract(interest).setScale(2, RoundingMode.HALF_UP); if (i terms) { // 最后一期把尾差补进本金 principalPart remainPrincipal; monthPay principalPart.add(interest); } remainPrincipal remainPrincipal.subtract(principalPart).setScale(2, RoundingMode.HALF_UP); // 组装 RepaymentPlan 对象并加入 list plans.add(new RepaymentPlan(i, monthPay, principalPart, interest, remainPrincipal)); } return plans; } }两个容易踩的坑都在代码里有体现。第一计算(1r)^n时不要用Math.pow它返回 double一旦期数超过 24 期尾差会明显放大手动循环乘法配合BigDecimal能保证精度可控。第二最后一期需要手工补差前面每期利息四舍五入到分本金也四舍五入到分最后一期要把剩余本金一次性算清否则整张借据永远无法平账。每月利率的计算必须保留至少 10 位小数最后到月供才四舍五入到分。如果一上来就把月利率转成两位小数整个还款计划利息会偏离一截。这个细节在面试里被问到“你们怎么处理金额精度”时是最能体现功底的回答点。4.3 提前还款剩余本金计算与账务冲正的边界处理提前还款分两种提前还清结清全部剩余本金和利息和提前部分还款。这里只讲提前结清因为逻辑最清晰也最能看出对账务的理解深度。关键问题是“剩余本金怎么算”。很多人直接拿总本金减去已还本金总和这在等额本息下是错误的因为每个月还款里的本金部分是变动的。正确做法是遍历还款计划表找到状态为“未还”的第一期把它的“剩余本金”字段取出来那才是当前的真实未还本金。public BigDecimal calcAmountToSettle(String loanNo) { Loan loan loanMapper.selectByLoanNo(loanNo); ListRepaymentPlan plans repaymentPlanMapper.selectByLoanNo(loanNo); BigDecimal remainPrincipal BigDecimal.ZERO; BigDecimal currentInterest BigDecimal.ZERO; for (RepaymentPlan plan : plans) { if (RepaymentStatus.UNPAID plan.getStatus()) { if (remainPrincipal.signum() 0) { remainPrincipal plan.getRemainPrincipal(); } // 当期未还利息需要结清 currentInterest currentInterest.add(plan.getInterest()); } } // 违约金按剩余本金 1% 计可配置 BigDecimal penalty remainPrincipal.multiply(new BigDecimal(0.01)) .setScale(2, RoundingMode.HALF_UP); return remainPrincipal.add(currentInterest).add(penalty); }这段代码把已还清和未还清的还款计划用状态位区分开避免依赖借据上的余额字段。借据表的本金是不变的还款计划表才记录逐期的本金摊销这就是把“账务事实”和“摊销计划”分离后的好处。提前结清会生成一笔交易流水把未还本金、当期利息和违约金分别记账然后批量更新剩余还款计划状态为结清。这样做的好处是后期对账时可以看到“这笔借据提前 N 期结清”而不是凭空消失。5. 把源码跑起来的避坑清单部署、精度与命名5.1 从本地到 LinuxJDK 版本、Maven 构建和数据源配置用一份干净的数据源配置打底本地能跑起来后面移到 Linux 只需要改 IP 和密码spring: datasource: url: jdbc:mysql://localhost:3306/credit_db?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai username: root password: your_password driver-class-name: com.mysql.cj.jdbc.Driver mybatis-plus: global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0 configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl本地跑通后打包部署的命令也很固定mvn clean package -DskipTests nohup java -jar credit-system-0.0.1-SNAPSHOT.jar \ --spring.profiles.activeprod \ credit.log 21 这里最容易翻车的点是 JDK 版本不一致。很多人电脑上既有 JDK 8 又有 JDK 17Maven 默认用高版本编译但 Spring Boot 2.7.x 在 JDK 17 下有些反射和 CGLIB 代理会出莫名其妙的警告Spring Boot 3.x 又必须用 JDK 17 以上。建议直接用 JDK 17 Spring Boot 2.7.x把pom.xml里的java.version设为 17然后统一本机和服务器 JDK 版本。5.2 金额精度与日期序列化Jackson 和时区造成的两个隐形错误现象一前端页面显示贷款金额 1000.00提交到后端后变成 1000.0甚至出现 999.9999999 这种值数据库里存的是 1000.00但接口回传时变成了科学计数法。原因Jackson 反序列化时把 JSON 里的数字默认读成Double如果字段类型是BigDecimal精度会在转换过程中丢失。解决在字段上统一加注解强制使用字符串序列化JsonSerialize(using ToStringSerializer.class) JsonDeserialize(using BigDecimalDeserializer.class) private BigDecimal amount;现象二数据库里的create_time是 14:00前端显示 22:00。原因JDBC URL 里没加serverTimezoneAsia/ShanghaiMySQL 驱动走的是服务器默认时区或者驱动用 UTC 解释时间。这是国产环境里最典型的时区坑。解决在数据源 URL 上显式指定serverTimezoneAsia/Shanghai同时把 Spring Boot 的spring.jackson.time-zone也设为GMT8两道配置都要有少一个都可能在某些接口上露馅。5.3 保留字表名与 MyBatis-Plus 乐观锁逻辑正确但代码报错的两类坑现象启动后执行建表脚本落到order表时报 SQL 语法错误查询loan表没问题但插入时报“Unknown column”。原因order是 MySQL 的保留字做表名或字段名时必须用反引号包起来。很多人实体类叫Order就顺手把表名也叫order在 MySQL 8 里直接撞上保留字。解决表名尽量用业务词避免关键字比如把订单表/借据表叫loan把还款计划表叫repayment_plan。实在无法避免时在TableName(order)里加反引号或者统一加前缀t_例如t_credit_order。前缀法在团队协作时还能避免多人建表互相覆盖。现象两个线程同时放款分别读到可用额度 10000 和 8000各自扣减后写回最终已用额度比实际放款总额少了一半。原因额度表更新用了“先查后写”的普通 update没有版本控制后写覆盖先写。解决额度扣减必须用乐观锁在实体上给版本字段加Version同时在 MyBatis-Plus 配置里注册乐观锁插件Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new OptimisticLockerInnerInterceptor()); return interceptor; }更新语句的写法也有一点讲究。不要先 select 拿到 version 再 update直接写条件更新update credit_limit set used_amount used_amount - #{deductAmount}, version version 1 where customer_no #{customerNo} and available_amount #{deductAmount}这样既做了额度下限校验又避免了并发覆盖。乐观锁那个Version在 MyBatis-Plus 里只对updateById生效如果你写的是自定义 SQL还是要自己在 where 里拼版本条件。6. 把授信逻辑抽成额度引擎统一额度控制器与手工验证很多毕设和中小公司的信贷系统最终都会卡在一个问题上额度扣减散落在放款、还款、退款多个接口里每个地方都写一遍available_amount - amount改规则时到处找。进阶做法是把所有额度的占用、释放、冻结统一到一个CreditQuotaEngine里所有入口只有一个。public interface CreditQuotaEngine { /** * 占用额度放款成功时调用 */ boolean occupy(String customerNo, BigDecimal amount); /** * 释放额度结清/提前还款时调用 */ boolean release(String customerNo, BigDecimal amount); /** * 冻结额度审批通过到放款前调用 */ boolean freeze(String customerNo, BigDecimal amount); }这个接口的核心价值在于所有上游业务只告诉引擎“我要占用多少钱”至于额度记录在哪个表、是否需要联动 Redis、是否要记流水全部由引擎内部决定。放款、借据、还款计划的生成在 Service 层编排额度变动在引擎层收敛代码里就不会出现“左边扣一次右边再扣一次”的双减问题。我习惯在交付前做一轮手工交叉验证拿一张 Excel 表格手动用等额本息公式算 3 组数据本金分别是 10000、23300、50000期数覆盖 3、12、36 期利率取一个常见的 7.2%然后把生成器的输出逐期对一遍。只要最后一期剩余本金是 0每期利息和本金都没有负数这套规则就基本站得住。别嫌这个方法土绝大多数翻车都不是在复杂规则上而是在最简单的数学运算上。另一个值得做的验证是并发压测用 JMeter 开 20 个线程同时对同一个客户发起放款请求看是否产生超额度放款。没有乐观锁时几乎必现加了where available_amount #{deductAmount}后稳定通过。我曾经带过一个新人他用double写了整个还款计划工具类我让他用 Excel 验一遍结果 36 期还完账上还剩下 0.18 元。从那以后我们组的规矩就是账务代码只准出现BigDecimal禁止把金额和利率声明成原生数值类型。希望这条习惯也能帮到你。本文还有配套的精品资源点击获取