简介面向需要快速搭建线上借贷业务的技术团队、独立开发者及高校相关专业学生这套全开源借贷 App 系统提供 uni-app 跨平台前端与 Java 后端分离架构覆盖移动端、管理后台、服务端及数据库等完整工程链路。压缩包共 8 个文件核心代码以 5 个 zip 分包保存包含 Uni 前端、后台网页、服务端程序、分发展示网页和数据库脚本同时附带 PNG 安装教程、HTML 说明页面以及 Nginx 配置示例整体大小约 22.42MB结构清晰便于按模块对照部署。系统已吸引 1077 人学习下载在借贷/金融类实战项目中具有一定参考热度。通过该源码包读者可获得一套可直接编译运行的前后端项目骨架以及环境配置思路既能用于业务快速上线也能作为课程设计、毕业设计或二次开发的基础底座省去从零搭建的重复工作。 前阵子有人问我想转行做金融科技方向的后端但手头没有一套真实的业务代码可以参照GitHub 上搜出来的开源借贷项目要么前端残缺要么后端连数据库脚本都没有。这种情况我见过太多。今天要说的这套 2023 全新借贷 APP 系统源码算是少见的完整货——前端是独立的 uni-app 工程后端是 Java整包全开源能建库导数据、能跑接口、能把一条借贷业务从申请到结清完整走通。无论你是准备做毕业设计、想转岗金融科技方向还是公司内部需要一个借贷类产品原型这套源码都能省下大量从零摸索的时间。1. 这套全开源借贷系统定位、组成与适合人群1.1 项目全景三端一体的完整闭环很多号称借贷系统开源的项目实际上只丢给你一堆页面模板或者一个半残的接口工程真要按照 README 跑起来比登天还难。这套源码我整体过了一遍属于工程完整度比较高的uni-app 写的独立前端一套代码可编译到 Android、iOS、H5、小程序等多个平台Java 后端以 Spring Boot 为主提供标准的 RESTful 接口另外还带管理后台用来做借款审核、用户管理、还款记录查询。从功能上看虽然借贷本身的业务模型不算复杂但真实系统该有的模块它基本都覆盖了用户注册登录、实名认证资料、借款申请、后台审核、合同生成、放款记录、还款计划、逾期处理。把这些模块串起来就是一条完整的金融业务链路。对于想学真实业务长什么样的人来说这套源码的信息量其实是很大的。1.2 三类最适合拿这套源码的人我根据自己的使用经验把适合的人群分成三类第一类是准备往消费金融、金融科技方向转岗的 Java 或前端工程师。很多人简历上写着熟悉借贷业务流程但真被问到借款状态怎么流转、逾期后还款计划怎么重算、审核拒绝后用户能不能再次发起借款一下子就露怯了。这套源码摆在那把核心代码读一遍这些问题都能找到答案而且是能落到代码层面讲的答案。第二类是在校生做毕业设计。借贷系统是典型的业务完整、技术点覆盖广的选题前端、后端、管理端、数据库设计、权限验证、状态机什么都有。拿这套开源代码做底子把界面换个主题、加个新功能已经不是从零起步而是站在一个能跑的工程上做增量答辩的时候也有东西可讲。第三类是有原型演示需求的团队或个人。比如内部员工借款、亲友间资金周转工具、培训机构分期缴费的演示系统拿这套源码去改比找外包从零报价省太多时间。但这里必须说清楚对外商用涉及到金融牌照和监管合规开源代码只是技术底座不是业务通行证这一点后面会展开讲。2. 技术选型为什么要盯准 uni-app Java 这对组合2.1 前端选 uni-app 的本质原因一次投入多端复用借贷类产品有一个很现实的特点用户在各端的分布是分散的。有人习惯装 App有人用微信公众号里的 H5还有人会从小程序入口进来。如果每个端都单独开发前端成本直接翻三倍维护起来更是灾难。uni-app 的价值就在这里——一套 Vue 代码编译到 App、H5、小程序逻辑层基本不用动。实际开发时你写的还是 Vue 单文件组件页面路由、组件化、状态管理这套思维和 Vue 2/3 完全一致差异点主要在平台 API 的封装上。比如uni.navigateTo、uni.request、uni.login这些统一 API底层会自动适配到各端原生能力。对借贷系统这种表单密集型应用来说表单校验、下拉刷新、图片上传、身份证 OCR 识别uni-app 的插件生态都有现成方案不用从零去造轮子。另一个不能忽略的因素是学习成本和招聘成本。现在的 uni-app 面试题出现频率已经很高了会写 uni-app 的前端不难找Vue 背景的人迁移过来基本无缝。对独立开发者来说一个人用一套代码维护多个端是性价比极高的选择。2.2 Java 后端为什么在金融系系统里依然能打后端选 Java核心不是性能最强而是稳定、生态全、人才多。金融业务的接口不会像高并发中间件那样动辄百万 QPS但它的难点在于事务一致性、状态管理的严谨性和审计追溯。Spring Boot 生态里Spring Data JPA / MyBatis、Spring Security、分布式事务中间件应有尽有做借贷这种强事务、强状态的业务非常顺手。再往深一层说Java 在信贷领域的技术积累非常厚。银行、消金公司的核心系统大量是 Java 系代码风格、接口设计、报表字段都有成熟的行业参照甚至像 ruoyi 这类优秀的 Java 开源框架也非常多。如果你去面试资深后端工程师借贷、支付这类业务是高频考察场景Java 生态里围绕这些业务的开源库、解决方案和踩坑记录也是最多的。出了 bug 能搜到大量答案这件事本身就比很多小众语言省下大量时间。2.3 前后端分离掩盖的三个协作成本这套系统是典型的前后端分离结构前端跑在开发服务器上通过 HTTP 调后端接口后端只出 JSON 数据和做权限校验。前后端分离的好处是两端可以并行开发只要提前把接口文档定好联调阶段再暴露问题即可。但代价就是下面三件事必须做扎实否则后面全是坑。第一前端要有统一的请求封装。一般会在项目里放一个request.js集中管理 baseURL、token 注入、响应拦截、错误提示而不是每个页面各写一份uni.request。第二后端要有统一的返回结构比如{ code, message, data }。这个结构虽然老套但是前后端协作的地基没有它前端处理异常会很痛苦。第三环境地址要按development、test、production拆开管理。我见过太多人把 baseURL 硬编码成 localhost结果打包上真机后连不上服务器通宵排查最后发现只是忘了改地址。前端工程里那行 baseURL看起来不起眼实际上是前后端协作里最容易翻车的基础配置。3. 借款业务链路拆解状态流转、核心表与合规红线3.1 从注册到结清的完整状态流转借贷系统的业务链路比普通商城系统更强调状态流转。整套流程大致是注册账号 → 实名认证和资料填写 → 提交借款申请 → 后台风控/人工审核 → 审核通过后签订合同 → 放款 → 生成还款计划 → 按期还款 → 结清销户中间还穿插着逾期处理、提前结清、展期等异常分支。我建议拿到源码先别急着跑而是把借款单状态这个字段彻底梳理清楚。通常一个借款单会包含这些状态当前状态允许的操作下一个状态待审核审核通过审核通过待审核审核拒绝审核拒绝审核通过签订合同待放款待放款确认放款还款中还款中按期还款 / 提前结清已结清还款中触发逾期已逾期每个状态之间哪些操作是合法的、哪些是非法跳转后端必须做硬性校验不能只靠前端按钮隐藏来控制。原因很简单接口是可以被绕过直接调的前端控制只是体验后端状态校验才是安全底线。做二次开发的人尤其要注意新增状态时一定要把这个状态机整体检查一遍不然就会出现已拒绝的借款单还能被改成放款中这种严重事故。3.2 几张核心表的设计思路这类项目的数据模型基本靠这几张表打底用户表user账号、密码加密存储、手机号、姓名、身份证号、实名认证状态。借款申请表loan_order关联用户记录金额、期限、利率、用途、状态、审核意见、放款时间。还款计划表repay_plan每个借款单拆成多期计划每期包含应还本金、利息、逾期罚息、应还日期、实际还款日期、状态。账户或流水表account_log记录用户资金变动、提现、还款流水方便对账。合同表contract审核通过后生成存合同编号、正文内容或文件地址。从设计角度看还款计划表是最容易出问题的点。等额本息和先息后本这两种还款方式每期的本金利息计算逻辑完全不同如果支持提前结清还涉及到已产生利息的重新核算。开源源码里一般只实现一种还款方式二开的时候想扩展成可配置的多种方式一定要在表里预留还款类型字段不要写死。3.3 风控与利率逻辑技术和合规必须分开看这是借贷系统中比较敏感但必须讲清楚的一部分。技术层面风控可以先从简单的规则引擎做起比如根据用户年龄、借款金额、期限、历史还款记录做一个可调整的评分规则数据层面可以接第三方征信或黑名单接口但这通常需要付费和相应资质。必须提醒一遍开源代码仅供技术学习与产品演示。如果要做面向公众的真实借贷业务必须取得相应金融业务资质严格遵守监管对利率上限、个人信息保护、借款用途的所有要求。很多开源项目在 README 里写仅限学习交流禁止商用不是套话是责任边界。技术能解决的是效率和体验业务本身的合法性需要由资质和制度来保证。4. 前端 uni-app 落地过程中的关键实现细节4.1 路由传参从表面能用到底层不出错许多人用 uni-app 时第一个卡住的就是获取路由参数。官方做法是uni.navigateTo({ url: /pages/loan/detail?id123 })然后在目标页面的onLoad(options)里取options.id。逻辑不复杂但实际开发中有两个高发问题。一是参数里有特殊字符、中文时容易乱码或丢失。例如借款金额、用户姓名直接拼到 URL 里目标页拿到的是乱码。稳妥做法是传参时用encodeURIComponent编码取出来再decodeURIComponent。如果是比较大的对象建议放进全局状态管理或本地缓存里别硬塞 URLURL 是有长度限制的。二是小程序端或 App 端在高版本基础上onLoad 拿到的参数顺序可能存在差异。我自己习惯在项目里封装一层参数解析函数统一处理字符串、数字、JSON 三种类型。这样页面里不用到处写取参 类型转换的重复代码也方便统一排查问题。4.2 分享、定位、隐私弹窗三个绕不开的细节有人问uni-app 自定义分享好友和uniapp onshareappmessage 被全局方法覆盖这些都是实操中非常典型的问题。小程序里自定义分享一般用onShareAppMessage但如果你在多个页面重复定义又抽了公共方法很容易互相覆盖。我惯用的做法是在公共 mixin 里定义一个全局默认分享配置某个页面需要定制分享标题和图片时再单独覆盖onShareAppMessage。覆盖时注意要保留from和target的默认逻辑否则会出现点了转发按钮却没有反应的诡异问题。高德地图导航是另一个常见需求借贷 App 里往往有线下门店、上门审核、公司地址之类的场景。其实 uni-app 里用uni.openLocation就能调起系统地图完成导航不需要额外引入高德 SDK 到原生层。这一块真没必要复杂化。还有一个很多人问的场景iOS App 在用户不同意隐私政策及用户协议时需要退出应用的代码怎么实现。合规上这个是必要功能可以在启动弹窗回调里判断用户选择不同意时调用uni.exitApp()。但注意 H5 端不支持该 API需要做降级处理iOS 审核对强制退出比较敏感退出前的文案要诚恳明确别让用户觉得是崩溃。4.3 下拉刷新与滚动冲突的处理逻辑还有一个控制细节值得单独说页面里如果有滚动区域同时又开启了enablePullDownRefresh经常会出现手指往下拉内容在滚动而不是触发刷新的问题。原理很简单下拉刷新手势和内部滚动的手势被系统同时识别发生争抢。解决办法有两种如果滚动的区域是scroll-view给scroll-y和refresher-enabled分开管理或者干脆在页面配置里关闭系统下拉刷新自己在scroll-view里做自定义刷新头。面试问到这类问题时能把冲突原理讲清楚比死记几个配置项强得多。5. Java 后端从接口到安全的实战要点5.1 工程结构、接口分层与状态机实现后端工程建议严格按照经典分层来做controller 只接收参数和做参数校验service 写业务逻辑mapper/DAO 管数据库entity 映射表结构。千万不要为了省事把业务逻辑堆在 controller 里。借贷业务的审核、计息、还款逻辑都是要反复测试和变更的堆在一起后面根本改不动。状态机部分尤其建议集中管理。不要在每个业务方法里用 if-else 判断状态是否合法而是定义一个状态流转处理器把当前状态 操作事件 → 下一个状态的映射关系集中在一张表或一个配置类里。审核通过、拒绝、取消申请的逻辑都收敛在一处后面改起来不会牵一发动全身。不少项目后期状态逻辑改一处崩三处罪魁祸首就是状态校验散落各处。5.2 Token 鉴权与 AES 加密盐的处理位置这类系统一般用 JWT 做登录态用户登录后后端生成 token前端每次请求放在 header 里后台通过拦截器校验 token 并解析用户身份。这里有个很容易踩的坑token 放在Authorization头还是自定义 header前后端必须严格一致同时拦截器必须对跨域预检的OPTIONS请求放行否则前端还没真正发起业务请求就被 403 挡住了。再说一个经常被问到的点AES 加密盐放后端。用户的手机号、身份证号这类敏感信息如果直接在数据库里明文存储一旦数据泄露就是严重事故。正确的做法是后端用 AES 加密后再入库密钥和盐值放在后端配置文件或环境变量里不参与前端打包。前端展示时由后端解密返回。盐和密钥绝对不要写进前端代码因为前端代码一旦上线反编译就能把密钥挖出来加密等于白做。想更稳的话建议把密钥放到配置中心而不是直接提交到 Git。5.3 跨域配置与联调阶段的常见坑前后端分离项目绕不开跨域问题。后端可以在 Spring Boot 里写一个全局 CORS 配置允许指定域名访问接口。开发阶段可以放开所有来源上线前再收紧成白名单。我踩过最典型的坑是前端用uni.request或 axios 时一旦 header 里带了自定义字段比如 token就会触发浏览器的预检请求。如果后端配置里没有显式允许这个 header接口会一直失败但浏览器控制台的报错又不明显。这时千万不要无头绪地改代码先打开开发者工具看网络面板里的OPTIONS请求是成功还是失败大部分的跨域问题都出在这一步。能看懂预检请求跨域问题就解决了一半。6. 从源码到上线的部署路径与二次开发建议6.1 本地初始化环境JDK、Maven、数据库先把环境准备干净否则后面全是低级报错。JDK 我建议用 Java 8 或 11很多开源项目直接跑在更高版本上会出现反射异常或者字节码不兼容问题。装完之后配好JAVA_HOME环境变量命令行里执行java -version和mvn -v确认版本没问题再继续往下走。用 IDEA 2022 打开工程后第一次会自动下载依赖如果你在 Maven 的settings.xml里配置了阿里云镜像下载速度会快很多不配置的话等依赖下载可能就要耽误半天。数据库方面先建好实例再按项目提供的 SQL 脚本导入表结构和初始化数据。这个阶段我见过的高频问题有两个一个是项目用的 MySQL 8 驱动本地却是 MySQL 5.7启动直接报协议不匹配另一个是数据库密码里带了特殊字符application.yml里没处理特殊字符导致连接失败。看报错日志时不要只盯最后几行要重点找Caused by后面的内容那才是真正的根因。6.2 打包部署时容易翻车的几个细节点后端打 jar 包部署前确认application.yml里激活的是生产环境配置而不是本地环境否则线上数据库连接串不对接口全部报错。前端 uni-app 打包时必须走发布模式别拿 HBuilderX 运行模式的包去提审这两个模式的差异和坑社区里已经有大量帖子了。H5 端部署到子目录时manifest.json里的运行基础路径必须改成相对路径或对应子路径否则打包出来的 JS、CSS 全部 404。App 端打包则要注意 manifest 里的应用名称、图标、包名、Android 签名证书尤其是证书——云打包和本地打包如果用不同证书上架后后续版本可能面临无法更新的问题。权限声明部分定位、相机、存储这些权限要根app实际功能保持一致和隐私政策里的说明能对得上。6.3 二次开发方向与一份实打实的建议如果有时间我建议优先往这三个方向扩展第一还款方式从一种扩展成等额本息、先息后本、随借随还多种第二加一个可配置的规则风控引擎让额度、期限、利率不写死在代码里第三把管理端的审核流程升级成多级审核。这三个方向做完你对整套系统的理解会上升一个层次面试或者实际做项目都会顺手很多。最后说句实在话开源代码给的是台阶不是终点。把这套源码当一个跑得通的业务参照物吃透状态流转、悟明白权限设计、再结合自己的场景做增删改这个过程本身比代码值钱得多。我这些年陆陆续续看过不少开源金融类项目能坚持把技术债还完、把文档补齐、把边界弄清楚的人后来不管是转业务专家还是继续做架构都走得更远。本文还有配套的精品资源点击获取