简介：一套基于uni-app框架开发的房贷计算器小程序源码包，面向小程序开发者和金融工具类应用学习者，可一键部署至QQ小程序与微信小程序等多端，覆盖商业贷款、公积金贷款两大常见计算场景。压缩包内共120个文件，包含25个Vue组件页面、25个JavaScript逻辑脚本、24个JSON配置、13个QML与13个QSS样式文件，以及PNG图标、SCSS/CSS样式和Markdown说明文档，整体体积约602KB，目录结构清晰，便于阅读和二次开发。当前已有1255人学习下载。源码完整展示了基于LPR利率的商业贷款计算与公积金贷款计算逻辑，涉及等额本息还款、复利计算以及Vuex状态管理、页面路由、axios网络请求等典型uni-app实践；同时包含iconfont图标、uni-popup弹窗组件应用实例，并带有错误处理与异常捕获机制。解压后导入HBuilderX等uni-app开发环境即可直接运行、调试与个性化修改，有助于系统掌握跨端工程搭建、组件化开发、API调用及与后台数据交互的完整链路。 前阵子有个朋友跑来问我，说想搞一个房贷计算器小程序，问我是用原生微信小程序写还是用uni-app写。我的回答很直接：如果只打算上微信小程序一个端，原生开发确实够用；但如果你愿意多花一点时间在uni-app上，后面能顺手把H5和安卓App一起出，这笔账非常划算。我自己手头正好有一套用uni-app写的房贷计算器源码包，是从一个已经跑过微信小程序、H5和安卓App的项目里抽出来的，结构不复杂，但核心算法和平台适配都已经验证过。这篇就把它从目录结构、算法实现、打包上线到二次开发的过程，完整拆开聊一聊。无论你是拿它做毕业设计、接私活，还是自己在公司里做一个贷款计算类的小工具，这篇应该都能帮你省下不少时间。
1. 源码包的项目结构：一个函数库和三个页面撑起整个应用
先别急着看算法，先把源码包的项目结构摸清楚。这套房贷计算器源码包用的是标准的uni-app Vue单文件组件结构，用HBuilderX打开后，目录大概是这样的：
project-root/ ├── pages/ │ ├── index/ # 首屏：贷款参数录入 + 计算结果简表 │ │ ├── index.vue │ │ └── index.scss │ ├── result/ # 结果明细：逐月还款计划表 │ │ ├── result.vue │ │ └── result.scss │ └── history/ # 历史记录：本地存储的最近20条计算 │ ├── history.vue │ └── history.scss ├── utils/ │ ├── loan.js # 核心贷款算法 │ ├── format.js # 金额、利率格式化 │ └── storage.js # 本地历史记录读写 ├── static/ │ └── tabbar/ # 底部Tab图标 ├── manifest.json # 应用配置/权限/小程序AppID ├── pages.json # 页面路由与导航栏配置 └── App.vue # 全局生命周期与公共样式这套结构最值得注意的一点是：UI相关的东西并没有做得多花哨，核心价值全部集中在utils/loan.js里。因为房贷计算器这类工具，本质上就是“输入参数 -> 计算 -> 展示结果”，数据模型和算法正确性比界面美观重要得多。pages/index/index.vue负责用户录入贷款金额、年利率、贷款年限、还款方式；pages/result/result.vue接收计算结果并渲染逐月明细；pages/history/history.vue则把用户最近算过的记录存到本地缓存，方便再次查看。
在实际项目中，我会建议你把utils/loan.js当成一个独立模块来维护，不要和页面逻辑混在一起。这样后续不管你是换UI框架，还是增加组合贷、提前还款功能，算法层都不用动，只改页面调用方式就行。源码包里的pages.json是uni-app的路由和导航配置文件，很多新手容易忽略它，实际上页面标题、tabBar、下拉刷新开关都靠它控制，后面的坑里我会专门讲到。
1.1 为什么选uni-app而不是原生小程序或Flutter
既然叫“uniapp小程序源码包”，那选型理由就得说清楚。我自己这几年用下来，对这几个方案的真实感受是这样的：
| 维度 | 原生微信小程序 | uni-app | Flutter |
|---|---|---|---|
| 多端复用 | 仅微信端 | 微信小程序 + H5 + App | App为主，小程序需额外适配 |
| 前端语法 | WXML/WXSS/JS | Vue/HTML/CSS | Dart |
| 学习成本 | 需要单独学小程序语法 | 懂Vue基本无缝上手 | 较高 |
| 插件生态 | 微信官方生态 | DCloud插件市场丰富 | 偏自建 |
| 打包流程 | 微信开发者工具 | HBuilderX云打包/离线打包 | 自行编译 |
选uni-app做房贷计算器，最重要的理由就是“一套代码多处跑”。如果你接了一个私活，客户今天说先上微信小程序，下个月又说要一个官网的H5版本，再过两个月说要安卓App，你用原生小程序写的话就得全部推翻重来，而uni-app只需要在条件编译层做一些平台差异处理，核心页面和算法完全复用。Flutter在小程序端的支持其实还在完善中，尤其是微信小程序这种需要大量调用平台能力的场景，Flutter并不比uni-App省心。
当然，这不是说uni-app没有缺点。它的问题在于，一旦你用到比较特殊的原生能力，比如自定义蓝牙协议、高精度定位插件，就得写条件编译代码，甚至用离线打包去集成原生SDK。不过对房贷计算器这种纯计算加列表展示的工具类应用来说，uni-app的生态完全够用，而且源码包跑通的三个端已经证明这条路是通的。
2. 房贷算法的正确打开方式：等额本息和等额本金一个都不能错
房贷计算器的核心，说白了就是两套公式：等额本息和等额本金。很多网上流传的源码包，表面上能算出个数字，但你和银行贷款对账单一对就会发现总额对不上。问题大多出在利率换算、浮点精度、还有还款明细的累计逻辑上。
2.1 利率和期数的换算细节，错一个数字全盘错
用户界面上输入的年利率，一般是“4.9”这种整数或小数形式，含义是4.9%。在做任何计算之前，必须先把它除以100，再除以12，得到“月利率”。这个换算看起来简单，但真的有人会在代码里只除以12，结果算出来的月供差出一大截。
// 年利率百分比转月利率 function getMonthlyRate(annualRatePercent) { return annualRatePercent / 100 / 12; }还款期数同样要小心：用户输入“30年”，不是直接当成30，要按照Math.round(years * 12)转成360个月。我建议在转换的时候顺手做个入参校验，比如贷款金额大于0、年利率在0到10之间、年限在1到40之间，否则后面Math.pow很容易算出NaN或者无限大。这类源码包最容易让人栽跟头的地方，不是公式本身，而是边界条件没有兜底。
2.2 等额本息：公式不复杂，边界条件才是坑
等额本息的月供公式是：
月供 = 贷款本金 × 月利率 × (1 + 月利率)^还款月数 / ((1 + 月利率)^还款月数 - 1)
代码实现其实很短：
function calcEqualInstallment(principal, annualRatePercent, years) { const months = Math.round(years * 12); const monthlyRate = annualRatePercent / 100 / 12; let monthlyPayment; if (monthlyRate === 0) { // 0利率时公式失去意义，直接本金平摊 monthlyPayment = principal / months; } else { const factor = Math.pow(1 + monthlyRate, months); monthlyPayment = principal * monthlyRate * factor / (factor - 1); } return { monthlyPayment: roundMoney(monthlyPayment), totalPayment: roundMoney(monthlyPayment * months), totalInterest: roundMoney(monthlyPayment * months - principal) }; }这里有个容易忽略的边界条件：当利率为0时，factor等于1，分母为0，整个公式直接出错。虽然现实里房贷利率极少为0，但万一用户的贷款产品有免息期，页面就会白屏。源码包里我补了这个兜底，直接按本金平均分摊到每个月，这也是我在实际修补中觉得最值得保留的一处。
另外要提醒的是，不要用四舍五入后的月供去反算总还款额。JavaScript里的浮点数有误差，如果你先roundMoney(monthlyPayment)把月供变成了两位小数，再用它乘以360个月，手工对账时会发现和银行少几分钱。正确做法是先保留完整的浮点结果做总账，最后展示到页面时再格式化。
2.3 等额本金：逐月递减的现金流怎么算才准
等额本金的逻辑更直白：每个月还的本金固定，利息根据剩余本金逐月减少，因此月供递减。
function calcEqualPrincipal(principal, annualRatePercent, years) { const months = Math.round(years * 12); const monthlyRate = annualRatePercent / 100 / 12; const principalPerMonth = principal / months; const records = []; let remaining = principal; for (let i = 1; i <= months; i++) { const interest = remaining * monthlyRate; const payment = principalPerMonth + interest; remaining -= principalPerMonth; records.push({ period: i, payment: roundMoney(payment), principal: roundMoney(principalPerMonth), interest: roundMoney(interest), remaining: roundMoney(remaining < 0 ? 0 : remaining) }); } return records; }这个函数返回的是完整的逐月明细数组，前端渲染时可以直接用。最后几期会有可能因为浮点计算让剩余本金变成-0.000000001这种值，所以输出时要做一次归零处理，否则表格里出现负数会给用户造成困惑。
等额本金和等额本息对用户的直观差异，用一张表就能看明白：
| 还款方式 | 首月月供 | 月末月供 | 总利息 |
|---|---|---|---|
| 等额本息 | 固定值 | 固定值 | 相对较高 |
| 等额本金 | 较高 | 较低 | 相对较低 |
很多房贷计算器源码包会把两种方式的结果放在同一个页面里做对比，方便用户决策，这个做法值得保留，因为用户关心的不光是月供多少，更关心哪个方案总利息更少。
2.4 展示层的金额格式化与精度处理
算法本身只是计算，真正让用户相信结果的是展示层的处理。在源码包里，我单独写了一个format.js，里面包含金额格式化和利率格式化两个基础函数：
export function roundMoney(value) { // 避免直接 toFixed 带来的浮点尾差，先放大取整再缩小 return Math.round((value + Number.EPSILON) * 100) / 100; } export function formatMoney(value) { return roundMoney(value).toFixed(2); }这里的关键点是：不要在整个计算过程中频繁四舍五入。正确做法是内部计算始终用浮点数，中间过程不丢失精度，只在数组输出或者页面绑定前调用roundMoney。这样既保证了明细表格里的数据清晰，又不会因为逐月取整导致总还款额前后不一致。
如果项目对金额精度要求特别高，更稳妥的方案是内部用“分”来存储和累加，展示时才除以100转成“元”。房贷计算器月供金额本身不大，浮点误差通常最多差几分钱，但如果你后面做的是大额贷款管理工具，建议还是从一开始就走“分”的路线，避免埋雷。
3. uni-app小程序端的经典坑位：从manifest配置到下拉刷新冲突
源码包能跑通算法只是第一步，真正让开发者在变成“血压升高”的，往往是uni-app在微信小程序端那一堆平台适配问题。下面几个坑，我在这个项目里几乎全踩了一遍。
3.1 微信登录失败的根因排查：AppID和合法域名是第一嫌疑人
很多刚拿到小程序源码包的人，第一步就卡在“小程序获取登录后的微信用户失败:wx1cb4398e1413dce7”这种报错上。这个报错的根因，绝大多数时候是manifest.json里配置的小程序AppID和你微信公众平台上注册的根本不是同一个。
排查路径其实很固定：先打开manifest.json，确认mp-weixin.appid是否填了正确的小程序AppID；然后到微信公众平台的“开发管理 -> 开发设置 -> 服务器域名”里，检查你请求的后端接口域名是否加入了request合法域名。如果你只是本地联调，可以在微信开发者工具的“详情 -> 本地设置”里勾选“不校验合法域名、web-view（业务域名）、TLS版本以及HTTPS证书”，这样请求能先通，但上线前一定要把域名配置补上。
另外一个容易忽略的点是基础库版本。uni-app编译出来的代码对微信基础库有自己的最低要求，如果开发者工具的基础库版本太旧，登录接口可能直接没反应。解决办法是把基础库调到2.7.3以上，这个版本之后eventChannel等很多跨页面通信能力才稳定。
3.2 输入框、键盘与条件编译的兼容性处理
房贷计算器页面需要用户输入贷款金额和年利率，我一开始直接用<input type="digit" />，结果在部分安卓机型上发现小数点死活打不出来。后来查了社区才知道，type="digit"在H5端和App端的表现并不完全一致，尤其某些安卓WebView会把小数点和数字键盘的坑踩得很深。
我的处理方案是加一个输入过滤函数，在@input事件里手动去除非数字和小数点：
function sanitizeNumberInput(value) { let val = String(value).replace(/[^\d.]/g, ''); const dotIndex = val.indexOf('.'); if (dotIndex !== -1) { val = val.slice(0, dotIndex + 1) + val.slice(dotIndex + 1).replace(/\./g, ''); } return val; }同时利用uni-app的条件编译，在微信小程序端保留type="digit"，在H5端可以退回type="text"配合正则过滤。条件编译是uni-app非常实用的能力，但很多人直到踩了键盘的坑才开始认真看文档。
3.3 页面下拉刷新和scroll-view滚动的冲突
项目里有个历史记录页面，原本想做成下拉刷新，于是我在pages.json里开了enablePullDownRefresh。结果用户用的时候发现，在scroll-view列表里往下滑，滑到顶部后再一拉，整个页面就开始转圈刷新，体验非常割裂。这个现象对应的热搜词就是“uniapp 下拉如何触动滚动屏而不触发页面下拉刷新”。
解决方案要看具体场景。对房贷计算器的历史记录页来说，历史记录本来就是本地缓存，根本不需要网络刷新，所以最干净的做法是把页面级下拉刷新关掉，只在scroll-view上启用自定义刷新能力。如果你确实需要页面级刷新，那就要放弃scroll-view，改用原生页面滚动，否则两个滚动体系叠加在一起永远会有冲突。
{ "enablePullDownRefresh": false, "backgroundTextStyle": "dark" }对于计算结果页，我的建议更激进：直接禁止整页滚动，让内容放在一个scroll-view里，这样既不会误触页面刷新，也能保证逐月明细可以独立滚动。
3.4 计算结果的跨页面传递：别把对象塞进URL
房贷计算器这个需求有一个很典型的场景：用户在首页点击计算，跳转到结果页，结果页要展示一整套逐月还款明细，这个明细可能有360条数据。如果新手直接把整个对象拼到URL里，比如/pages/result/result?data=...，很快就会遇到两个问题：URL长度被微信小程序限制，以及对象里的特殊字符被转义后解析不出来。
正确做法是用uni-app封装好的eventChannel，从首页跳转时把结果数据传过去：
uni.navigateTo({ url: '/pages/result/result', success(res) { res.eventChannel.emit('loanResult', { paymentList: records, total: totalInfo }); } });结果页在onLoad里接收：
this.getOpenerEventChannel().on('loanResult', (res) => { this.loadData(res); });这个方式在微信基础库2.7.3以上没问题，源码包里已经做了兼容判断。如果运营环境里还有老版本微信，保险方法是用uni.setStorageSync临时存一份，结果页读取后再清理。我的习惯是两种都写上，核心数据用eventChannel，展示用的辅助数据走本地缓存，这样双保险。
4. 从源码到上架：HBuilderX打包和安卓市场适配
源码包在自己的项目里跑通不算完，真正交付给用户是要打包上线的。这里我重点说微信小程序端和安卓App端的完整流程，顺便把云打包和离线打包的区别讲清楚。
4.1 微信小程序端的发行与预览流程
如果你用的是HBuilderX，流程其实很顺。先确认manifest.json里的mp-weixin.appid已经填好，然后点菜单栏“发行 -> 小程序-微信”，HBuilderX会自动编译生成dist/build/mp-weixin目录。然后打开微信开发者工具，选择“导入项目”，目录指向刚才生成的那个文件夹，而不是整个uniapp根目录，这一点太容易搞错了。
导入后先在开发者工具里跑一遍交互，重点看有没有报request正式域名错误、有没有样式错乱。确认没问题后，点开发者工具右上角“上传”，填上版本号和备注，代码就会进到微信公众平台的“版本管理”里。接下来在公众平台提交审核、发布上线。
如果你在源码包里做了“关于页面”，需要跳转一篇公众号文章，一定要记得在公众平台“设置 -> 业务域名”里配置对应的业务域名，否则用户点击时小程序无法打开公众号文章，会提示需要配置。这属于上线前很容易漏掉的一步。
4.2 云打包与离线打包的区别：什么时候选离线
要做安卓App的话，HBuilderX提供两种打包方式：云打包和离线打包。
云打包非常简单，直接在HBuilderX里选择“发行 -> 原生App-云打包”，填好App图标、证书别名、证书密码，云端帮你把APK构建出来。免费用户会有排队和次数限制，但用于个人项目或者交付demo已经足够。它的最大问题是你没法在打包过程中插入自定义原生代码，比如某些第三方支付SDK、特殊蓝牙模块，必须依赖离线打包。
离线打包则需要你先下载DCloud官方的Android离线SDK，然后用Android Studio打开一个空工程，把uni-app的资源放进assets/apps目录，再配置包名和AppKey。这个流程明显更重，但好处是你可以随意修改原生层代码，集成任何自有SDK。房贷计算器这种应用，如果只是上普通应用市场，云打包完全够用；但如果客户要求集成他们自己的一套原生统计SDK，那就必须走离线打包。
4.3 上架安卓应用市场前要准备的资料
源码包可以帮你节省写代码的时间，但上架安卓应用市场这件事，跟源码包关系不大，更多是资质和合规的准备。我整理了一下常见渠道的硬性要求：
- 软件著作权登记证书：很多应用市场要求提供，个人申请或企业申请均可。
- 隐私政策：小程序和App都要有，尤其涉及用户存储历史记录时，需要写明数据存储位置和用途。
- 应用签名文件：发布APK时必须用同一个签名文件进行签名，签名信息一旦丢失，后续无法覆盖更新。
- 应用截图与图标：各渠道尺寸要求不同，通常是高清截图加圆角图标。
另外现在国内应用市场普遍要求App填写备案信息，这一点需要在打包前就确认好。上架审核遇到最多的驳回理由，一是隐私政策里没有明确说明数据使用范围，二是targetSdkVersion版本不符合要求。我的建议是，把源码包里的App版本号、显示名称、应用图标这些信息一次性改好，再根据目标市场要求补材料，别等代码写完才想起这些事。
5. 二次开发指南：组合贷、历史记录和分享功能扩展
源码包最大的价值不在于“拿来就能跑”，而在于“在它基础上能改成你想要的产品”。这个房贷计算器项目，我后来接了几个变体需求，这里把最常见的三个扩展方向说透。
5.1 从单一房贷扩展到组合贷的改造思路
很多用户的需求不是纯粹的商业贷款，而是“商业贷款 + 公积金贷款”的组合贷。改造思路其实不复杂：把首页的输入参数从一组变成两组，然后在算法层做一次合并。
function calcCombined(commercialLoan, fundLoan) { const commercialRecords = calcEqualPrincipal(commercialLoan.principal, commercialLoan.rate, commercialLoan.years); const fundRecords = calcEqualInstallment(fundLoan.principal, fundLoan.rate, fundLoan.years); const maxLen = Math.max(commercialRecords.length, fundRecords.length); const merged = []; for (let i = 0; i < maxLen; i++) { const a = commercialRecords[i] || { payment: 0, interest: 0, principal: 0, remaining: 0 }; const b = fundRecords[i] || { payment: 0, interest: 0, principal: 0, remaining: 0 }; merged.push({ period: i + 1, payment: roundMoney(a.payment + b.payment), interest: roundMoney(a.interest + b.interest), principal: roundMoney(a.principal + b.principal), remaining: roundMoney(a.remaining + b.remaining) }); } return merged; }这里要特别注意的是两种贷款的期限可能不同，比如商业贷款20年、公积金贷款30年，合并时较短的那组在后期应该按0处理，而不是报错。我上面的代码用空对象兜底，就是这个目的。
5.2 历史记录存储与自定义分享的落地写法
源码包里的历史记录模块，用的是最简单的本地缓存方案。在storage.js里封装读写函数，每次计算完成后往数组头部插入一条记录，只保留最近20条：
export function saveHistory(record) { const list = uni.getStorageSync('loan_history') || []; list.unshift({ ...record, timestamp: Date.now() }); uni.setStorageSync('loan_history', list.slice(0, 20)); }微信小程序的分享功能也很适合放进房贷计算器，毕竟用户算完月供第一反应往往是发给家人商量。自定义分享可以直接在页面配置onShareAppMessage：
export default { onShareAppMessage() { return { title: `月供${this.monthlyPayment}元，总利息${this.totalInterest}元`, path: '/pages/index/index' }; } }这样可以做到用户分享时，卡片标题直接带上计算结果，打开率会比默认“房贷计算器”高不少。这个细节在源码包里已经写好了，直接改页面数据名就能用。
5.3 我给这个源码包打的三个补丁
最后说点更实战的。这个源码包我拿到手之后，并没有直接上生产环境，而是先打了三个补丁，这三个补丁也是我建议你拿到任意类似项目后优先做的事。
第一个补丁是金额精度。原来内部用元做浮点累加，360个月的数据累计下来，总利息和银行对账单总是差几分钱。我把内部计算改成了以“分”为单位，展示时再转换成元，对账问题直接消失。
第二个补丁是0利率边界。原代码完全没有考虑免息贷款的情况，factor - 1一旦为0，结果页直接空白。补上之后，凡是利率为0的贷款都按本金平摊计算，页面再也没出现过白屏。
第三个补丁是输入防抖。原页面每次键盘输入一个数字就会触发一次全量计算，用户输入“360000”的时候页面会明显卡顿。我给输入框的@input事件加了一个300毫秒的防抖，等用户停止输入后再计算，体验立刻流畅了很多。
这三个补丁看着不起眼，但正是源码包能不能从“demo”变成“可交付产品”的关键。你拿到代码后，先别急着改UI，把贷款金额、利率、年限输进去，再用银行或者其他贷款App的还款计划对一遍总数和逐月明细，把精度和边界这类细节先修好，后面再怎么扩展都不会翻车。
本文还有配套的精品资源，点击获取
