Mortgage calculator
Amortisation tables for equal instalments / equal principal, plus a savings comparison for the two early-repayment options (shorter term / lower payment).
贷款信息
利率请照你的贷款合同填写(4.9 只是常见默认值)。本页不预设「当前利率 / LPR」——政策一变,写死的数字就变成错误信息。
留空则明细表不显示日期。填了也只是从首次还款日逐月推进(如 1/31 → 2/28),不推算任何银行计息天数。
修改上面任意一项后会自动重算;也可以点「开始计算」。输入不合法时会就地报错(例如期限 0、利率填成文字),不会给出一个看起来正常、其实错误的结果。
等额本息还是等额本金?提前还款该怎么选?
两种还款方式的差别,本质是「先还利息多还是先还本金多」。等额本息每月还的钱一样多,但前期利息占比极高:以 100 万 / 30 年 / 4.9% 为例,首期月供 5307.27 元里有 4083.33 元是利息,只有 1223.94 元在还本金;到最后一期,5305.19 元里几乎全是本金。好处是月供固定、好记账、前期压力小;代价是整笔利息更多(约 91.06 万)。等额本金每月还的本金固定(100 万 / 360 期 = 2777.78 元),再加上当期剩余本金的利息,所以首月 6861.11 元、之后每月递减约 11.34 元,末月只剩 2788.32 元;总利息约 73.70 万,比等额本息少约 17.36 万。代价是前期月供高出一大截,对现金流要求更高。怎么选没有标准答案:收入稳定、前期现金流紧、想把每月支出钉死,选等额本息;前期还款能力强、在意总利息、或有提前还款打算,选等额本金更划算。银行通常两种都支持,签合同前可以先各算一遍再定。
提前还款「缩期限」和「减月供」差多少。同一笔 100 万 / 30 年 / 4.9% 的等额本息贷款,第 12 期后一次性还 10 万:选「缩短期限、月供不变」,剩余期数从 348 期缩到 281 期,总利息从 91.06 万降到 65.13 万,省 25.93 万;选「减少月供、期限不变」,月供从 5307.27 元降到 4768.44 元,总利息只降到 82.31 万,省 8.75 万。两者差了 17 万多——原因很直白:缩期限是让本金"更早退场",占用的计息时间短;减月供则只是把同样的本金摊到同样长的 348 期里慢慢还,利息自然省得少。所以纯从省钱角度看,缩期限永远更优;但如果月供压力已经很大,减月供换来的是现金流安全,这份安全感本身也有价值。
为什么第 1~5 年提前还款省的利息最多。因为利息是按「当期剩余本金」算的,而本金在整个还款期里是前慢后快。等额本息尤其明显:还满 5 年(60 期)时,100 万的贷款大约只还掉 7 万多元本金,剩余本金还有 92 万多——此时提前还 10 万,等于砍掉了一大块"还要被计息 25 年"的本金。反过来,还到第 20 年时剩余本金本就不多、剩余计息时间也短,同一笔 10 万能省的利息可能只有此时的几分之一。所以提前还款这件事,"越早越省",但前提是:先留够 6~12 个月的应急现金、并且确认没有更高利率的负债(如信用卡分期、消费贷)要先还。
为什么我们不做「当前利率」预测或自动填入 LPR。房贷利率由「LPR + 加点」决定,LPR 每月报价、加点各行不同、重定价日还可能按合同约定在每年 1 月 1 日或放款对应日调整。任何写死在页面里的"当前利率"都会在政策变动后变成错误信息,而一个房贷计算器给出错误利率,比不给利率糟糕得多。所以本页把利率完全交给你填,只给一个常见值(4.9)作为占位,并在结果里反复提醒"以你的贷款合同为准"。同理,本页不做"要不要提前还款"的结论——那取决于你的资金成本、流动性和贷款合同条款,不是算术题。
为什么贷款金额和利率不上传到服务器。这一页不需要任何服务器算力:所有公式和逐期摊销都在你自己的浏览器里跑,输入的数字既不进数据库也不写日志——你可以打开开发者工具的 Network 面板,整个计算过程没有任何请求发出。我们刻意不做"上传后云端计算",一是因为这类信息(贷款金额、利率、剩余本金)和工资条一样敏感,二是算 360 期摊销本来就不需要服务器。唯一的例外是"导出 CSV":那份文件由浏览器在本地生成并直接下载到你的电脑,同样不经过我们。
FAQ
Usually a different interest convention, not a mistake. This page takes the monthly rate as annual rate / 12, rounds each period's interest to the cent, and settles the remaining principal in full on the last period (so the final payment can be a few cents or yuan above the regular one). Banks may compute interest on actual days (each month has a different count) or apply their own rounding rules, and across hundreds of periods a gap of tens of yuan is normal. For exact reconciliation use the schedule issued by your bank; this page's value is comparing options against each other.
That is the final-period adjustment, not a bug. Each period's interest and principal are rounded to the cent, and over hundreds of periods a residue of cents or yuan accumulates; the last period settles the remaining principal in one go, so its amount differs slightly from the regular payment. Conversely a final payment smaller than the regular one (also common) is the same residue effect. The result explicitly flags whether the last period was adjusted and by how much.
Pure savings: shortening the term wins, because principal leaves the interest base earlier. For example, 1,000,000 over 30 years at 4.9%, prepaying 100,000 after the 12th period: interest saved by shortening is roughly three times that of lowering the payment. But if the payment already makes you afraid of losing your job, lowering it buys monthly cash-flow safety, which is also worth something. Before signing, always confirm with the bank: which handling is the default, whether there is a penalty or fee, and whether you get a new amortization schedule after the recalculation.
Zero rate takes its own branch: payment = principal / periods, total interest is exactly 0, no division by zero, no NaN. A term of 0, negatives or non-numbers are rejected in place - you never get a 'looks normal' result. Tiny inputs like 1 yuan over 1 period compute normally (principal 1.00, interest 0.00). And if a payment cannot even cover the current period's interest (debt snowballing), the page says outright that no amortization schedule can be produced - it will not grind out a fake one.
No. The CSV carries a UTF-8 BOM, so Excel (Windows included) reads Chinese correctly; amounts are written as plain two-decimal numbers without thousands separators, so Excel cannot split one figure into two cells at a comma. The file is generated locally in your browser and downloaded directly - it never passes through the server.