百分比计算器

最常见的两个算错

第一个是反推原值。含税价 113 元、税率 13%，不含税价应该是 113 ÷ 1.13 = 100 元，而不是 113 × 0.87 = 98.31 元。差别在于 13% 是相对不含税价算的，所以反推时必须除以 1 + 13%；直接乘 1 - 13% 相当于把分母换成了含税价，结果必然偏小。金额越大、税率越高，差得越多，财务场景下这个错误很致命。

第二个是百分点和百分比混用。从 5% 到 7%，说「涨了 2 个百分点」是准确的，说「涨了 2%」就错了（相对涨幅其实是 40%）。这类指标包括存款利率、失业率、患病率、投票支持率、市场占有率——它们本身就是百分比，所以变动必须用「百分点」描述。基数越小，两种说法的差距越夸张，5% 涨到 7% 是 40% 的相对涨幅，读新闻时值得回头确认一眼原始数字。

为什么百分比不能直接相加

涨 10% 再跌 10% 不等于回到原点。原因是每次变化的基数都在变：先涨 10% 后基数变成了原来的 1.1 倍，再跌 10% 是拿这个更大的数去跌，结果是 1.1 × 0.9 = 0.99，比原来少 1%。同理，「满 200 减 30」再打 9 折也不是优惠 25%，而是 0.85 × 0.9 = 0.765，实际优惠 23.5%。

可靠的做法是把每一步都写成一个乘数，最后连乘。加价 15% 乘 1.15，打 8 折乘 0.8，亏损 30% 乘 0.7，这样无论顺序怎么变、有几步，结果都不会算错。上面「连续多次变化」这个模式做的就是这件事，同时还给出「直接相加会得到多少」，方便你核对差在哪里。

跌了之后要涨多少才回本

这也是分母变化带来的不对称。100 元跌 50% 变成 50 元，要回到 100 元需要涨 100%，而不是 50%。跌得越多，回本需要的涨幅增长得越快：跌 20% 要涨 25%，跌 50% 要涨 100%，跌 80% 要涨 400%。「变化率」这个模式里会同时给出上涨幅度和「要变回去需要多少」，两相对照就很容易记住这个规律。

判断一笔投资或一次调价的真实影响时，建议同时看百分比和绝对金额。百分比便于横向比较不同规模的对象，绝对金额则不容易被小基数放大出来的夸张百分比误导。两个数放在一起，结论通常就稳了。

关于精度

计算全程用 JavaScript 的双精度浮点数，它遵循 IEEE 754 标准，所以像 0.1 + 0.2 这类运算会得到 0.30000000000000004。这个工具统一保留 6 位有效数字后再显示，把这类噪声挡在显示层之外。如果用于财务结算，建议在拿到结果后按业务规则再做一次四舍五入，而不是直接依赖显示出来的数值。

先确定分母再动笔。百分比算错的九成原因不是乘除，而是分母选错了。同一个「涨了 20%」，以成本为分母是说利润率，以售价为分母是说毛利率，两个数完全不同。动笔前先在心里明确一句「拿什么做分母」，比事后对几遍算式都有用。

百分点和百分比是两回事。从 5% 到 7% 是 2 个百分点，也是 40% 的相对涨幅，两个说法都对但语境不同。统计公报、央行报告里的「利率下调 25 个基点」是 0.25 个百分点；媒体标题写「支持率大涨 40%」时，读者最好回头确认一下原始数值是不是从 5% 变成 7%。基数小的时候，相对变化会显得夸张。

变化和恢复不对称。跌 50% 需要涨 100% 才能回到原值，涨 100% 只需要跌 50% 就回去了。这种不对称来自分母不同，不是算术错误。判断一笔投资或者一次调价的真实影响时，看绝对金额比看百分比更不容易被误导，尤其是幅度超过 20% 之后。

浮点运算的尾巴。0.1 + 0.2 在 IEEE 754 双精度里等于 0.30000000000000004，所以百分比计算经常出现 16 位小数。这个工具统一保留 6 位有效数字后再显示，就是要把这类噪声挡在外面。如果是财务场景，建议在拿到结果后再按业务规则做一次四舍五入，而不是依赖显示值。

打折叠加不等于折扣相加。「满 200 减 30」再「打 9 折」，实际折扣不是 15% + 10% = 25%。正确做法是先把两个系数乘起来：0.85 × 0.9 = 0.765，也就是打了 76.5 折、优惠 23.5%。促销规则越复杂，越应该把每一步写成一个系数再连乘，而不是累加优惠幅度。