简介：全新借贷APP系统源码（2024年版）是一套面向开发者的完整借贷平台技术方案，集成独立uni前端与Java后端，覆盖前台展示、后台管理、服务器配置和数据库脚本等环节，适合有Web或移动端基础的技术人员快速搭建自有借贷业务。整套源码共1141个文件，以JS、Vue、HTML等前端代码为主，并包含Java服务端文件、JSON配置、SQL数据库脚本及Nginx配置示例，压缩包大小约21.91MB，目录按nginx、web、site、p2p、dk等模块划分，便于按需查看。目前已有593人学习下载。其中p2p(uniapp)部分实现了借款人与出借人的直接对接，配合后台管理系统和服务器端脚本，可形成从界面交互、业务处理到数据存储的完整运行闭环；同时附带160个PNG、79个GIF等界面素材，开发者可直接调整前端视觉与交互细节，省去大量基础搭建工作，快速进入业务定制与功能迭代阶段。
1. 借贷APP源码里的“独立”能帮你省多少事：uni前端与java后端的分工边界
“全新借贷APP系统源码——2024年版独立uni前端、java后端”，这句话真正值得先琢磨的不是“全新”，而是“独立”。市面上标着借贷APP源码的东西不少，但很多是前后端写死在一起的：改个logo要翻遍整个WebView，换个接口地址要重新出包，想在H5和小程序之间复用界面还得再养一套代码。这个标题说的“独立”，指的是前端用uni-app这一套跨端框架，后端用Java那一套成熟服务端技术栈，两边各自独立成工程，中间只靠接口对话。你拿到手的是两个可以分别编译、分别部署、分别替换的半成品工程，而不是一团谁也拆不开的乱麻。
借贷类产品和其他App有个明显差别：业务链路长，涉及借款申请、授信额度、放款、还款计划、逾期罚息这些环节，任何一个环节出问题都不只是界面难看，而是账对不上、钱算错。所以这种源码的落地路径，大多不是“下下来就能跑”，而是要把前端页面骨架和后端业务状态机分别看明白，再把它们接到一起。这篇笔记就按“前端怎么立起来 → 后端怎么把钱和状态算对 → 联调部署有哪些参数要设 → 哪些坑会让项目翻车”这个顺序拆一遍，适合打算基于这套东西做二次开发、或者想把它改造成自己业务模型的开发者读。
2. uni前端落地：借贷申请、支付拉起、还款计划三个核心页面的代码骨架
先说明白：uni前端不是写死在某台手机里的原生界面，它是一套基于Vue语法的跨端工程。跑起来以后，一份代码能同时出Android、iOS、微信小程序和H5。但“跨端”不等于零成本，网络层、登录态、支付拉起的写法都得按uni的规矩来。借贷App里无论如何绕不过的有三块骨架：请求层封装、借款申请页、还款计划展示。把这几个页面先跑通，这套App的“壳”就立住了，后面接什么业务都顺手。
2.1 请求层封装：baseURL、登录态与统一错误提示
不管页面长什么样，请求层是所有业务的地基。我一般会把uni.request再包一层，统一处理baseURL、token注入、超时和错误提示。这样页面里写业务代码时不需要反复纠结接口地址和状态码，后端接口路径调整时也只改一处。
// utils/request.js const BASE_URL = 'https://api.example.com' // 联调时改成局域网IP或测试环境域名 export function request(path, { method = 'GET', data = {}, auth = true } = {}) { return new Promise((resolve, reject) => { uni.request({ url: BASE_URL + path, method, data, header: { 'Content-Type': 'application/json', // 如果接口需要登录态，就从本地缓存里取token带上 Authorization: auth ? uni.getStorageSync('token') : '' }, timeout: 15000, success: (res) => { // 约定后端返回格式为 { code, msg, data } if (res.data.code === 0) { resolve(res.data.data) } else if (res.data.code === 401) { // token失效：清掉本地登录态，跳回登录页 uni.removeStorageSync('token') uni.reLaunch({ url: '/pages/login/index' }) reject(res.data) } else { uni.showToast({ title: res.data.msg, icon: 'none' }) reject(res.data) } }, fail: (err) => { uni.showToast({ title: '网络异常，请稍后重试', icon: 'none' }) reject(err) } }) }) }逻辑说明：这段封装的职责是“把接口返回统一成Promise”，页面代码只用关心业务数据，不用每次写success/fail回调。BASE_URL单独拎出来，是为了后续打包时按环境切换地址——测试环境、生产环境域名不一样，只改这里就行。
参数说明：method默认GET，有POST的请求传参时覆盖；auth默认true，像登录接口、图形验证码这类不需要token的接口置为false，避免带上旧token造成误判；timeout设15秒，借贷接口里有些审批查询比较慢，太短会误报失败。401分支单独处理，是因为借贷系统的token一旦失效，继续带着旧身份请求会导致额度、借款单状态全是错的。
2.2 借款申请页：从授信额度到提交借款单的数据流
借款申请页是借贷App的核心操作页。页面要干的事很直接：展示当前可用额度，让用户填借款金额、选期数，然后提交申请。但背后有两条线不能乱：一是数据线，页面初始化要拉额度接口；二是操作线，提交接口要防重复点击。
// pages/loan/apply.vue 核心逻辑（Vue3组合式API写法） import { ref, onMounted } from 'vue' import { request } from '@/utils/request.js' const availableAmount = ref(0) // 可用额度，单位：分 const applyAmount = ref(null) // 用户输入的借款金额，单位：元 const termList = ref([3, 6, 12]) // 可选期数 const selectedTerm = ref(6) // 默认选6期 const submitting = ref(false) // 提交锁，防重复点击 async function loadQuote() { const res = await request('/loan/quote', { method: 'GET' }) // 后端口径：金额一律用分，避免浮点误差 availableAmount.value = res.availableAmount } async function submitApply() { if (submitting.value) return if (!applyAmount.value || applyAmount.value <= 0) { uni.showToast({ title: '请输入借款金额', icon: 'none' }) return } const amountInCents = Math.round(applyAmount.value * 100) if (amountInCents > availableAmount.value) { uni.showToast({ title: '金额超过可用额度', icon: 'none' }) return } submitting.value = true try { // clientReqNo由前端生成，用于幂等：同一个流水号后端只接受一次 const clientReqNo = Date.now().toString(36) + Math.random().toString(36).slice(2, 8) await request('/loan/apply', { method: 'POST', data: { amountInCents: amountInCents, term: selectedTerm.value, clientReqNo: clientReqNo } }) uni.showToast({ title: '申请已提交', icon: 'success' }) } finally { submitting.value = false } }逻辑说明：页面把“元”转成“分”再提交，是因为浮点数在计算机里表示不精确，金额这种字段一旦用浮点运算，累计下来会出现几毛钱的对不上账。这属于从后端到前端的全局约定——接口传输和存储都不用浮点数。clientReqNo是借款申请的幂等键，前端生成一次，后端用唯一索引兜底，这样就算用户连点两次提交，后端也只会创建一笔借款单。
参数说明：termList根据后端产品配置返回，不能写死，因为不同借款产品支持的期数可能不同；availableAmount是从授信接口拿的，页面不能自己算；submitting是一个操作锁，防止提交期间用户反复点击产生重复单。这里还有个容易被忽略的点：提交成功后不要马上跳转，要给后端一点点处理时间。我习惯提交成功后延迟800毫秒再跳转到“借款记录”页面，让用户看到明确的结果反馈。
2.3 支付与还款展示：uni.requestPayment 与还款计划渲染
借贷App里的“支付”不是普通商城支付，而是“放款资金到账”或“还款扣款”。以还款为例，常见流程是：前端调后端下单接口，后端返回一个支付参数对象，前端拿着这个对象调uni.requestPayment拉起支付。支付成功后，后端回调更新还款状态，前端再刷新还款计划。
async function repay(orderId) { const paymentParams = await request('/repay/createOrder', { method: 'POST', data: { orderId: orderId } }) // paymentParams形如 { timeStamp, nonceStr, package, signType, paySign } uni.requestPayment({ provider: 'wxpay', timeStamp: paymentParams.timeStamp, nonceStr: paymentParams.nonceStr, package: paymentParams.package, signType: paymentParams.signType, paySign: paymentParams.paySign, success: () => { // 支付成功，不要在这里直接改还款状态 // 以后端回调为准，这里只刷新页面 loadRepayPlan() }, fail: (err) => { uni.showToast({ title: '支付未完成', icon: 'none' }) } }) }逻辑说明：支付参数必须由后端生成，前端不能自己拼签名。原因很简单，支付签名涉及商户密钥，密钥放在前端等于公开。前端拿到参数后原样传给uni.requestPayment，支付结果以支付渠道回调后端为准，前端成功回调只做UI刷新。这套逻辑在微信小程序、App端都适用，只是provider可能不同——App端还可能是支付宝等其他渠道。
还款计划的渲染就朴实很多：后端返回一个包含每期本金、利息、应还日、状态的数组，前端用v-for渲染成列表。唯一要注意的是金额展示口径。用户习惯看“元”，但接口返回是“分”，这里必须有一个明确的分转元方法，不能有的页面转有的页面不转。
// utils/format.js export function centsToYuan(cents) { return (cents / 100).toFixed(2) }参数说明：centsToYuan统一在工具函数里做格式化，页面只负责展示。这样做的好处是格式统一，不会出现“有的页面显示1000，有的页面显示10.00”这种低级但致命的口径混乱。还款计划页要注意状态字段的展示优先级：已还、待还、逾期。逾期要标红并展示罚息，这里不要等后端返回逾期金额再显示，前端可以根据“应还日小于今天且未还”这个条件先做视觉提醒，后端再做最终金额计算。
3. java后端落地：借款单状态机、还款计划生成与资金流水
前端的壳立住之后，真正决定这套借贷源码能不能用的是后端。借贷业务后端的核心不是CRUD，而是三件事：借款单状态怎么流转、还款计划怎么算、放款前后资金流水怎么记。这三件事做好，系统就稳了一大半；做不好，前端页面再漂亮也是空中楼阁。常见做法是Spring Boot为主框架，配合MyBatis这类持久层框架，数据库用MySQL。下面按数据模型、核心接口、资金记账三层来拆。
3.1 数据模型：借款单、还款计划、资金流水的关系
先把表关系理清。标题说的是借贷APP，所以至少要有这三张核心表：借款单、还款计划、资金流水。借款单是主表，记录借了多少钱、分几期、当前什么状态；还款计划是借款单的子表，一期一行，记录每期还多少本金多少利息、哪天还、还了没有；资金流水是独立的账本，记录每一笔钱进出的痕迹，放款、还款、罚息扣款都要落流水。
-- loan_order：借款单主表 CREATE TABLE loan_order ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(64) NOT NULL COMMENT '借款单号，对外展示用', user_id BIGINT NOT NULL COMMENT '借款人ID', product_id BIGINT NOT NULL COMMENT '借款产品ID', amount_cents BIGINT NOT NULL COMMENT '借款金额，单位分', term INT NOT NULL COMMENT '期数', status VARCHAR(32) NOT NULL COMMENT '状态：AUDITING/APPROVED/LOANED/REPAYING/FINISHED/OVERDUE', client_req_no VARCHAR(64) NOT NULL COMMENT '前端幂等号', create_time DATETIME NOT NULL, update_time DATETIME NOT NULL, UNIQUE KEY uk_client_req_no (client_req_no) ); -- repayment_plan：还款计划，一期一行 CREATE TABLE repayment_plan ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(64) NOT NULL, period INT NOT NULL COMMENT '第几期', principal_cents BIGINT NOT NULL COMMENT '本期本金', interest_cents BIGINT NOT NULL COMMENT '本期利息', due_date DATE NOT NULL COMMENT '应还日期', status VARCHAR(32) NOT NULL COMMENT 'UNPAID/PAID/OVERDUE', paid_time DATETIME DEFAULT NULL, UNIQUE KEY uk_order_period (order_no, period) ); -- account_flow：资金流水账本 CREATE TABLE account_flow ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(64) NOT NULL, flow_type VARCHAR(32) NOT NULL COMMENT 'LOAN/REPAY/OVERDUE_FINE', amount_cents BIGINT NOT NULL COMMENT '本次变动金额，单位分', balance_cents BIGINT NOT NULL COMMENT '变动后的账户余额', create_time DATETIME NOT NULL );参数说明：amount_cents字段类型用BIGINT，从物理层面保证金额不会出现小数。client_req_no加唯一索引，这是防重复提交的最后一层防线——就算前端锁失效、用户连点两次，第二次插入也会因为唯一键冲突被数据库挡掉。repayment_plan的uk_order_period保证同一笔借款单不会出现两期重复数据。
这里有个设计取舍要说明：为什么借款单主表不直接保存“剩余应还总额”，而要每次都从还款计划表聚合计算？因为还款计划是逐期生成的，每一期还有单独的分期状态，主表如果冗余一个总额，很容易在部分还款后跟子表对不上。省那一次查询的代价是账目不一致，不值得。
3.2 核心实现：借款申请接口与等额本息计划生成
借款申请接口是后端的第一个核心入口。它的职责不只是“插入一条借款单”，而是要在事务里完成三件事：校验用户额度、创建借款单、生成完整还款计划。这三件事要么全成，要么全不成，所以必须在同一个@Transactional事务方法里完成。
// 常见做法：Spring Boot + MyBatis-Plus，ServiceImpl里写核心逻辑 @Service public class LoanOrderServiceImpl { @Transactional(rollbackFor = Exception.class) public String applyLoan(LoanApplyRequest req) { // 1. 幂等校验：同一个clientReqNo不能重复创建 LoanOrder exist = loanOrderMapper.selectByClientReqNo(req.getClientReqNo()); if (exist != null) { return exist.getOrderNo(); // 已处理过，直接返回原单号 } // 2. 额度校验：可用额度必须足够 BigDecimal available = creditService.getAvailableAmount(req.getUserId()); if (available.compareTo(req.getAmountCents()) < 0) { throw new BizException("可用额度不足"); } // 3. 创建借款单，初始状态AUDITING（待审批） LoanOrder order = new LoanOrder(); order.setOrderNo(generateOrderNo()); order.setUserId(req.getUserId()); order.setAmountCents(req.getAmountCents()); order.setTerm(req.getTerm()); order.setStatus("AUDITING"); order.setClientReqNo(req.getClientReqNo()); loanOrderMapper.insert(order); // 4. 生成还款计划 RepaymentPlanGenerator generator = new RepaymentPlanGenerator(); List<RepaymentPlan> plans = generator.generate(order.getOrderNo(), req.getAmountCents(), req.getTerm(), req.getProductId()); repaymentPlanMapper.batchInsert(plans); return order.getOrderNo(); } }逻辑说明：幂等校验放在事务最前面，但不是唯一防线——数据库的唯一索引uk_client_req_no是最终兜底。这里同时做两层是因为“先查再插”在并发下可能有缝隙，数据库索引兜底才能保证100%不重复。额度校验用compareTo而不是直接比较大小，因为BigDecimal的equals会连精度一起比较，0和0.00会被当成不相等，这是用BigDecimal最容易踩的一个坑。
还款计划的生成是数学问题，以等额本息为例：每期还款额相同，但本金和利息的分配逐期变化。计算要用BigDecimal的divide，并且要指定精度和舍入模式，否则会出现“算到最后总额差一分钱”的情况。
// 等额本息还款计划生成器 public List<RepaymentPlan> generate(String orderNo, long amountCents, int term, Long productId) { // 月利率由产品配置决定，注意年利率转月利率是除以12，不是除以365再乘30 BigDecimal monthlyRate = getMonthlyRate(productId); BigDecimal amount = BigDecimal.valueOf(amountCents); // 月供 = 本金 * 月利率 * (1+月利率)^期数 / ((1+月利率)^期数 - 1) BigDecimal onePlus = BigDecimal.ONE.add(monthlyRate); BigDecimal pow = onePlus.pow(term); BigDecimal numerator = amount.multiply(monthlyRate).multiply(pow); BigDecimal denominator = pow.subtract(BigDecimal.ONE); BigDecimal monthPay = numerator.divide(denominator, 2, RoundingMode.HALF_UP); // 保留2位小数 List<RepaymentPlan> plans = new ArrayList<>(); BigDecimal remaining = amount; LocalDate dueDate = LocalDate.now().plusMonths(1); // 首期次月同日 for (int i = 1; i <= term; i++) { // 本期利息 = 剩余本金 * 月利率 BigDecimal interest = remaining.multiply(monthlyRate).setScale(0, RoundingMode.HALF_UP); BigDecimal principal = monthPay.subtract(interest); // 最后一期做差额修正：剩余本金直接作为最后一期的本金，防止误差累积 if (i == term) { principal = remaining; } if (principal.compareTo(BigDecimal.ZERO) < 0) { throw new BizException("还款计划计算异常"); } remaining = remaining.subtract(principal); // ... 组装RepaymentPlan，设置期数、本金、利息、应还日 dueDate = dueDate.plusMonths(1); } return plans; }参数说明：这个计算里最关键的参数是RoundingMode.HALF_UP和最后的本金修正。每一期利息都经过四舍五入，如果最后一期不修正，把所有舍入误差累积起来，最后一期的本金可能比实际多几分钱。修正方式是倒数第一期直接用“剩余本金”作为本金，利息照算，这样最后一期还完，剩余本金正好归零。dueDate用plusMonths，自然月对应，1月31日借款，2月没有31日，Java会顺延到2月28日或29日，这是要考虑的细节，比硬算30天更符合还款直觉。
3.3 资金记账：放款成功后的余额与流水一致性
借款单审批通过后要放款。放款这个动作，在系统里要同时改三个地方：借款单状态从APPROVED改成LOANED、用户账户余额增加、资金流水新增一条放款记录。这三个操作必须在一个事务里。如果只改状态不加余额，用户看到的是“已放款但钱包里没钱”；如果只加余额不写流水，后面对账就抓瞎。
@Transactional(rollbackFor = Exception.class) public void disburseLoan(String orderNo) { // 加锁：查询借款单并用乐观锁防止重复放款 LoanOrder order = loanOrderMapper.selectByOrderNoForUpdate(orderNo); if (order == null) { throw new BizException("借款单不存在"); } if (!"APPROVED".equals(order.getStatus())) { throw new BizException("当前状态不可放款，状态：" + order.getStatus()); } // 1. 更新借款单状态为LOANED loanOrderMapper.updateStatus(orderNo, "LOANED"); // 2. 可用额度扣减：借款金额从授信额度中扣掉 creditService.deductAvailable(order.getUserId(), order.getAmountCents()); // 3. 账户余额增加，并写资金流水 Long balance = accountMapper.addBalance(order.getUserId(), order.getAmountCents()); accountFlowMapper.insert(new AccountFlow(orderNo, "LOAN", order.getAmountCents(), balance)); }逻辑说明：selectByOrderNoForUpdate是数据库行锁，意思是查出来的时候就把这一行锁住，别的事务想同时改这笔单必须等。这是防止“同一笔借款单被两条线程各放一次款”的常规做法——状态判断在并发下不是绝对安全的，配合行锁才稳妥。addBalance返回的是变动后的余额，直接作为流水里的balance_cents，保证流水里的余额是连续的，对账时能从头加到尾验证一致性。
这里有个容易被忽略的点：放款状态更新和账户余额增加必须在同一个事务里，但“放款成功”如果走的是异步回调，比如对接资金方接口，那回调顺理成章地处理会在另一个方法里。异步回调场景下的事务边界要特别小心，不能让“资金方已放款”和“系统记账”出现跨系统的不一致——这就是第5章要说的坑之一。
4. 前后端联调与独立部署：环境配置、接口约定与打包参数
前端和后端都是独立工程，它们之间唯一的连接是“接口约定”。约定没定好，联调时就会各种莫名其妙：前端拿到的是字符串，后端返回的是数字；前端传的是元，后端收的是分。独立部署听起来高大上，落到实处其实就是三件事：接口约定统一、本地联调跑通、打包含配置正确。这三件事做完，这套源码才算真正能上线用起来。
4.1 接口约定先行：统一响应体、时间格式与金额单位
前后端联调最怕的不是代码写错，而是两边对接口的理解不一致。我习惯先定一个文档级别的约定，再动手改代码。约定就三条：响应格式统一、时间格式统一、金额单位统一。
// 统一响应体格式 { "code": 0, // 0成功，非0失败 "msg": "success", // 错误信息 "data": {} // 业务数据 }// 后端统一响应体定义 @Getter public class ApiResult<T> { private final int code; private final String msg; private final T data; public static <T> ApiResult<T> success(T data) { return new ApiResult<>(0, "success", data); } public static <T> ApiResult<T> error(int code, String msg) { return new ApiResult<>(code, msg, null); } }参数说明：code=0约定为成功，非0为业务失败。为什么不用HTTP状态码直接当业务码？因为HTTP状态码语义有限，比如参数校验失败用400还是422，不同后端有不同理解，业务上不统一就容易出歧义。定一个业务码规范，前端只判断code==0，错误提示用msg，逻辑简单不会理解偏差。
时间格式统一推荐yyyy-MM-dd HH:mm:ss，时区用GMT+8。这个约定要写进接口文档，否则后端返回时间戳，前端又要做一遍时区转换。前端可以用这个规则解析，也可以直接用字符串展示。
// 后端返回的时间字符串，前端按约定直接格式化 export function formatTime(dateStr) { if (!dateStr) return '-' // 输入形如 2024-06-01 10:00:00 return dateStr }4.2 本地联调：CORS、代理与模拟登录
独立前后端工程在本地联调时，最常碰到的不是业务问题，而是“前端跑在HBuilderX的浏览器里，后端跑在本地8080端口，跨域了”。解决办法有两种：后端开CORS，或者前端起代理。我建议开发阶段用代理，因为代理不会污染后端的生产接口配置。
// manifest.json 或 vite.config.js 里配置代理 // 以HBuilderX内置浏览器联调为例，baseURL改为相对路径 const BASE_URL = '/api' // 开发环境走代理，生产环境改为正式域名 // vite.config.js 里做代理转发 server: { proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true, rewrite: (path) => path.replace(/^\/api/, '') } } }参数说明：target指向本机后端服务地址，rewrite把/api前缀去掉，后端不用额外处理前缀。这样前端代码里写的request('/loan/quote')在开发环境实际请求的是http://localhost:8080/loan/quote。生产环境不需要代理，所以BASE_URL要按环境区分——这是“独立”工程的典型配置方式。
模拟登录也是联调阶段的刚需。借贷系统的接口大部分要带token，每次联调都走一遍手机号验证码太慢。我习惯在后端留一个仅测试环境开启的“万能验证码”接口，或者在前端存一个写死的测试token，放到本地的uni.setStorageSync('token', 'test-token')里。生产环境务必关掉，这个开关要用配置控制，不能靠删代码。
4.3 独立部署：H5打包、Android包与后端jar的最小配置
前端独立部署要分清三个产物：H5是纯静态文件，丢到nginx就行；微信小程序要在微信开发者工具里上传；Android和iOS要出安装包。后端独立部署就是一个Java的jar包，配上数据库和配置文件就能跑。
先看前端H5打包。uni-app用HBuilderX打包时，在manifest.json里配置应用名称、AppID。H5打包的核心是“路由模式”和“接口地址”。路由模式要用hash模式，不要用history——因为history模式部署到nginx后，用户刷新页面会404，得额外配nginx转发。
// 生产环境接口地址放在环境配置文件里，不写死在代码中 // 例如 .env.production VITE_API_BASE_URL=https://api.example.com# 打包命令（以cli工程为例） npm run build:h5 # 产物在 dist/build/h5 目录，把这个目录整个上传到nginx的html目录后端jar包部署更直接。application.yml里重点配三块：数据库连接、redis地址、业务参数。业务参数里至少要有借款产品的利率配置和放款账户配置。
server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/loan_app?useUnicode=true&characterEncoding=utf8 username: loan_user password: 你的密码 redis: host: localhost port: 6379 loan: # 业务方利率配置，单位：年化百分比 product: 1: annualRate: 14.4 maxTerm: 12 2: annualRate: 18.0 maxTerm: 6参数说明：annualRate是年化利率，后端计算月利率时要除以12再除以100。注意这里要区分“名义年化”和“实际年化”，等额本息的实际年化利率计算复杂，做产品展示时不要让前端自己去算年化，要由后端返回到期总利息，前端直接展示金额。jar包跑起来命令很简单，java -jar loan-backend.jar --spring.profiles.active=prod，环境切换靠profile实现，这是Java后端最标准的部署方式。
5. 借贷APP源码落地避坑：5个会让项目翻车的隐藏问题
独立前后端工程落地，代码写完只是开始，真正让人头疼的是那些“跑起来能通、一上线就出问题”的隐藏坑。下面这5个问题，是我在类似项目里反复见到过的，每一条都真实发生过。现象、原因、解决办法列清楚，照着检查能少踩不少坑。
5.1 金额精度：浮点数和分元不统一，对账全乱
现象：用户借10000元分12期，按期还款后系统显示“还剩0.01元未还”，但用户已经还完最后一期。或者后台对账时总流水差了几毛钱，怎么都查不出来。
原因：代码里用了double或float存金额，或者前端传和后端收的口径不一致——前端传元，后端按分收，有的接口又返回元，几处一混，金额就乱了。浮点数的二进制表示本身就存在精度误差，多次运算后误差会累积到“可见”的程度。
解决：金额字段全链路只用两种类型：数据库BIGINT、JavaBigDecimal、前端JavaScript直接用整数“分”。前端页面展示时再转成元，但这个转换只发生在UI层。接口传输一律用分。所有涉及金额的运算，必须用BigDecimal的add/subtract/multiply/divide，禁止用原生加减乘除。最后再补一条强制校验：所有金额相关的接口入参，如果出现小数，后端直接拒绝并返回“金额格式错误”。
5.2 重复提交：借款申请没有幂等，出双单是必然
现象：用户在借款申请页网络卡顿，以为没点上，又点了一次提交。结果后台出现两笔一模一样的借款单，额度被扣了两次。
原因：前端按钮做了禁用，但网络请求超时后按钮锁会释放，用户在“请求超时”提示后再次点击，就会发起第二次请求。前端锁只能防正常的连点，防不住“超时后重试”这种场景。
解决：前端生成clientReqNo传给后端，后端在loan_order表上建唯一索引。第一次提交成功，第二次提交带着同样的clientReqNo时，数据库唯一索引直接拦截。后端看到重复的幂等号不要报错，应该返回第一次创建的orderNo，前端拿到后提示“申请已提交，请勿重复操作”。幂等键的生成规则要保证唯一性，用时间戳加随机数是一种常见做法，也可以用后端的UUID，但要注意UUID太长做业务流水号不友好，可以生成后截取。
5.3 登录态：微信小程序和App的授权逻辑不能共用一套代码
现象：同一份uni-app代码，H5和App端登录正常，发布到微信小程序后，手机号授权登录一直失败，报“invalid code”。
原因：uni-app的uni.login在不同端返回的code用途不一样。微信小程序里uni.login拿到的code要换openid和session_key，必须走小程序的appid + secret；App端如果是用“手机号一键登录”或“微信登录”，对接的是开放平台的appid。有的开发者图省事，把一端写死的appid用到了所有端，换一个端就必挂。
解决：登录逻辑按条件编译拆开写。#ifdef MP-WEIXIN走小程序的uni.login；#ifdef APP-PLUS走App的登录SDK；H5走账号密码或短信验证码。后端接口要区分channel参数，小程序和App的appid配置在后端，前端不能硬编码这些密钥。
5.4 还款计划：用“工作日”还是“自然日”，逾期天数直接算错
现象：一笔还款应还日是周末，用户周一还款，系统显示“逾期1天”，但用户认为周末不算工作日，拒绝认罚息。另一笔还款遇到了法定节假日，系统算出来的逾期天数和业务方对不上。
原因：业务方要求“遇节假日顺延”，但代码里用的是自然日计算逾期。还款计划生成时用plusMonths确实能保证每个月同一日，但顺延逻辑没有做，导致用户和业务方对逾期天数的理解不一致。
解决：还款计划生成时，如果应还日落在周末或法定节假日，顺延到下一个工作日。这里要注意顺延规则必须由业务方确认，有的借贷产品节假日不顺延，按自然日计算，有的顺延。规则确认后，在后端配置一个HolidayUtil工具类，内部维护一份节假日表，生成计划时判断是否顺延。逾期罚息计算也要用同一个工具类，保证“应还日”和“实际还款日”之间的天数计算口径一致。
// 逾期天数计算：节假日顺延后，用ChronoUnit算天差 public long calcOverdueDays(LocalDate dueDate, LocalDate paidDate) { LocalDate effectiveDue = HolidayUtil.nextWorkdayIfHoliday(dueDate); return ChronoUnit.DAYS.between(effectiveDue, paidDate); }5.5 放款记录：钱到账了，流水表却查不到
现象：用户看到“已放款”，钱包余额也增加了，但后台的资金流水表里查不到放款那条记录。月底对账时，总流水和银行流水对不上。
原因：放款操作对接了资金方接口，资金方回调“放款成功”后更新了借款单状态和余额，但更新代码和写流水代码不在同一个事务方法里，或者回调处理时直接抛异常被吞掉，流水没落库。更隐蔽的原因是：回调接口被重复调用，第一次写入流水成功，第二次因为唯一索引冲突抛异常，导致状态更新回滚。
解决：放款流水必须和状态更新、余额变动在同一个@Transactional事务里。资金方回调接口要做幂等处理——用orderNo加唯一索引存一条“放款回调记录”，第一次处理成功后，第二次直接返回成功，不重复执行。同时流水表里加一个biz_id字段，存本次放款的唯一业务ID，用于排查“哪个环节漏了流水”。对账脚本定期跑：借款单LOANED状态的单子，必须存在对应的LOAN流水，没有就告警。
6. 进阶玩法：给这套源码预留风控判断位与信审流程位
借贷APP跑通借款、放款、还款的基础链路之后，别急着上线。我见过太多项目因为“跑通了”就直接上生产，结果用户一多，资质差的人混进来，逾期率飙升。所以这里写三个进阶的落地技巧：风控规则预留位、信审流程位、以及一套完整的验证习惯。这三件事不复杂，但能让这套源码具备真正的业务生命力。
6.1 风控规则接口：在借款审批前留一层可插拔判断
借款申请状态从AUDITING到APPROVED，中间应该插入风控判断。常见做法是定义一个RiskControlService接口，初始实现只做基础校验：用户黑名单检查、借款金额上限检查、近期借款频次检查。后续接第三方风控时，只需要新增一个实现类，不用改借款主流程。
public interface RiskControlService { RiskResult check(LoanApplyRequest req); }参数说明：RiskResult里至少要有pass和reason两个字段，pass表示是否通过，reason表示拒绝原因。借款审批流程里调用这个接口，被拒就把reason作为借款单的拒绝理由存下来，用户能看到明确反馈。这样设计，后续接新风控就是加一个@Service实现类的事，不用动核心业务代码。
6.2 信审流程位：用状态字段扩展人工审核链路
不是所有借款都能全自动审批。金额大、风控没把握的单子，需要一个MANUAL_REVIEW状态。这个状态加在AUDITING和APPROVED之间，借款单状态字段里预留：AUDITING → MANUAL_REVIEW → APPROVED。人工审核通过就置为APPROVED，拒绝就置为REJECTED，并记录审核人和审核备注。
-- 借款单增加人工审核相关字段 ALTER TABLE loan_order ADD COLUMN review_status VARCHAR(32) DEFAULT NULL, ADD COLUMN review_remark VARCHAR(255) DEFAULT NULL, ADD COLUMN review_user VARCHAR(64) DEFAULT NULL, ADD COLUMN review_time DATETIME DEFAULT NULL;参数说明：这组字段是典型的流程预留位。默认NULL表示不经过人工审核；一旦进入人工审核，赋值状态和备注。前端借款记录页根据review_status显示审核进度，用户能看到“正在人工审核中”，产品体验完整。接OA或审批流时，把这几个字段对接过去，改动成本也小。
6.3 验证习惯：跑通一笔完整借款-放款-还款链路再交付
最后说一个我的习惯：每次改完代码，不急着看单个接口的测试报告，而是手动跑一遍完整链路——注册新用户、获取授信、提交借款、审批通过、放款入账、按期还款、提前结清、再看逾期罚息。跑完核对三张表：借款单状态、还款计划每期金额、资金流水的余额连续性。这三张表对得上，才算一次交付完成。这个习惯救过我很多次，因为很多bug藏在状态流转的边界里，单测很难覆盖到。
这套源码能不能直接用，取决于你对业务的认真程度。前端骨架是壳，后端状态机和流水是里子，风控和信审是长期跑下去的安全带。按这个顺序落一遍，比拿到源码直接跑起来有意义得多。希望帮到你。
本文还有配套的精品资源，点击获取
