复利计算禁用 math.pow 防浮点误差，应改用 for 循环迭代并控制舍入；利率需转为整数分处理；连续复利用 math.exp；须严格校验输入合法性并优先明确合同计息规则。
Math.pow 计算复利时的精度陷阱
直接用 Math.pow 算复利，结果常和 Excel 或财务系统对不上——不是算法错，是浮点误差在累积。比如年利率 5.5%，本金 10000，存 3 年：Math.pow(1 + 0.055, 3) 返回约 1.174241375，但 IEEE 754 双精度无法精确表示 0.055，实际参与运算的是 0.055000000000000006，微小偏差乘上本金和年数后会被放大。
- 别用
Math.pow直接套年复利公式principal * Math.pow(1 + rate, years)做资金结算 - 若必须用，先将利率转为整数分（如 5.5% → 550 分），再用整数幂逻辑模拟（见下一条）
- 前端展示可接受，后端记账、利息分润等场景必须换方案
用 for 循环替代 Math.pow 实现可控精度复利
复利本质是迭代：每期用上期本息 × (1 + 单期利率)。循环不依赖浮点幂运算，每步可插入舍入控制，更贴近真实计息规则。
function compoundInterest(principal, rate, periods) {
let balance = principal;
for (let i = 0; i
-
Math.round(... * 100) / 100强制截断到分，避免浮点累加漂移 - 若按日计息（periods 达 3650），循环性能无压力；万级周期才需考虑优化
- 银行常用“积数法”，此时应改用
principal * (1 + rate * periods)，而非幂运算
遇到小数次方（如 2.5 年）必须用 Math.pow 吗？
不一定。复利合同通常约定“按年结息，不足一年按单利折算”，即：2.5 年 = 2 年复利 × 0.5 年单利。强行用 Math.pow(base, 2.5) 会引入无意义的数学连续性假设，且底数为负或零时抛 NaN。
- 拆解逻辑：
compoundInterest(principal, rate, 2) * (1 + rate * 0.5) - 检查
base是否 > 0：复利基数不能为负，Math.pow(-2, 2.5)在 JS 中返回NaN - 若真需连续复利（如期权定价），用
Math.exp(rate * time)更准确，它底层调用 C 的 exp 函数，比Math.pow稳定
Node.js 和浏览器中 Math.pow 行为一致吗？
一致。ECMAScript 标准强制要求 Math.pow 遵循 IEEE 754-2008，所有合规引擎（V8、SpiderMonkey、JavaScriptCore）对相同输入返回相同输出。但要注意环境差异带来的间接影响：
- Node.js 默认启用
--harmony，某些旧版本 V8 对Math.pow(0, 0)返回1（标准行为），而极老浏览器可能返回NaN - 移动端 WebView 可能使用系统 WebKit，但现代 iOS/Android 已统一为最新 JS 引擎，无需额外兼容
- 真正要盯的是输入值合法性：确保
rate是有限数字，periods是非负整数（否则复利无业务意义）
复利计算最易被忽略的，是“计息规则”本身不在代码里，而在合同条款中。写死一个 Math.pow 公式，不如先确认清楚：是按日计息、按季结转、还是到期利随本清？不同规则对应完全不同的迭代逻辑，而不是换一个函数就能解决。
