IEEE 754 浮点数转换器

Q: 为什么 0.1 + 0.2 不等于 0.3？

0.1 和 0.2 的二进制都是无限循环小数，存储时已各自截断一次，相加后再舍入一次，结果是 0.30000000000000004——所有 IEEE 754 语言（JS/Python/Java）都一样。

Q: JS 的 Number 是单精度还是双精度？

双精度 float64。JS 只有一种数值类型 Number（BigInt 除外），安全整数范围是 ±2^53−1。

Q: 指数位的「偏置」是什么？

为了能比较大小和表示负指数，真实指数加上一个固定值（单精度 127）存储：存 127 表示 2^0，存 130 表示 2^3。

Q: 0.1 + 0.2 为什么不等于 0.3？

0.1 和 0.2 在二进制里都是无限循环小数，就像十进制的 1/3 = 0.333... 永远写不完。计算机只能存有限位，各自截断后相加，结果比 0.3 略大（0.30000000000000004）。十进制能精确表示的数，二进制未必能。

Q: 金额计算应该怎么避免浮点误差？

三条铁律：① 用整数存最小单位（分而非元，￥19.99 存 1999）② 必须用浮点时先转整数再运算 ③ 展示前四舍五入到 2 位（toFixed(2)）。金融系统用 decimal/BigDecimal 十进制类型，从根上消灭二进制误差。

Q: JavaScript 的整数最大是多少？

Number 类型能精确表示的最大整数是 2^53 − 1 = 9007199254740991（Number.MAX_SAFE_INTEGER），超过它相邻整数会无法区分（9007199254740992 + 1 算出来等于自己）。大整数用 BigInt，订单号、雪花 ID 超过 16 位就必须上。

Q: NaN 为什么不等于自己？

这是 IEEE 754 的刻意设计：NaN 表示「未定义或不可表示的运算结果」（0/0、∞−∞），两个错误结果没有理由相等。判断 NaN 必须用 Number.isNaN()，用全等比较永远是 false——这是 JS 里唯一一个不等于自身的值。

Q: float 和 double 什么时候用哪个？

默认 double：内存不再是瓶颈，16 位精度能覆盖绝大多数业务。float 只在三个场景有优势：GPU 图形渲染（海量顶点，带宽敏感）、机器学习推理（精度够且速度快一倍）、嵌入式传感器（存储与算力受限）。

Q: 为什么 9999999999999999 会变成 10000000000000000？

16 个 9 超过了双精度 15-16 位的有效数字能力，尾数存不下就四舍五入到最接近的可表示数——恰好是 10^16。银行卡号 19 位、身份证 18 位都超此限，所以这类编号在 JS 里必须当字符串处理，绝不参与数值运算。

Q: 浮点数能直接比较大小吗？

大于小于可以，判等要小心。两个本该相等的浮点结果可能差最后一位（如 0.1+0.2 vs 0.3），正确做法是比差值：|a − b| < ε（如 1e-9）即视为相等。单元测试里的近似断言（toBeCloseTo）就是这个原理。

什么是IEEE 754 浮点数转换器？

IEEE 754 是浮点数的国际标准：单精度 32 位 = 1 符号位 + 8 指数位 + 23 尾数位；双精度 64 位 = 1 + 11 + 52。数值表示为 (−1)^符号 × 1.尾数 × 2^(指数−偏置)，单精度偏置 127、双精度 1023。

十进制小数大多无法精确表示为二进制分数：0.1 的二进制是无限循环 0.0001100110011…，只能截断存储，这就是 0.1 + 0.2 = 0.30000000000000004 的根源。金融计算必须用整数（分）或十进制库，比较浮点数要用误差范围（|a−b| < ε）而非等号。

IEEE 754 还有几个特殊值：非规格化数（指数位全 0，表示接近 0 的极小值）、无穷（指数全 1、尾数全 0，如 1/0）、NaN（指数全 1、尾数非 0，如 0/0 或 sqrt(−1)）。判断 NaN 不能直接比较（NaN≠NaN），必须用 isNaN()。工程上 0.1 不是 0.1、1e16+1 还是 1e16，都是因为双精度只有约 15–16 位有效十进制数字——大数运算、比较浮点相等、累加求和时尤需警惕精度误差累积。

浮点转二进制的应用场景明确：调试大数据序列化（Protocol Buffers、JSON 里的数字）、排查跨语言精度不一致（同为 double 但一语言四舍五入一语言截断）、理解性能（软浮点平台浮点运算慢）、校验二进制协议报文里的小数字节序。本工具把 float32/double64 的二进制布局逐位展开，让你直观看到符号位、指数位、尾数位如何共同决定一个浮点值，从而理解精度损失的来源。

值 = (−1)^S × 1.M × 2^(E−127)（单精度）/ 2^(E−1023)（双精度）

IEEE 754 单精度 32 位结构：符号位 1 位 + 指数 8 位（偏置 127）+ 尾数 23 位。示例：5.75 = 101.11（二进制）= 1.0111 × 2^2 → 符号 0、指数 2+127 = 129（10000001）、尾数 0111 补 0 到 23 位。经典反例：0.1 的二进制是无限循环小数 0.00011001100...，存入 23 位尾数必然截断，所以 0.1 + 0.2 = 0.30000000000000004——这是所有语言的通病，不是 bug，是二进制表示的物理极限。

IEEE 754 两种精度对照
项目	单精度 float32	双精度 float64
总位数	32 位	64 位
符号/指数/尾数	1 + 8 + 23	1 + 11 + 52
精度（十进制）	约 7 位有效数字	约 15-16 位有效数字
最大安全整数	2^24（16777216）	2^53（9007199254740991）
典型应用	GPU、图形、传感器	通用计算、JS 默认 number

如何使用IEEE 754 浮点数转换器

1
输入一个十进制数（如 0.1）。
2
查看 float32 与 float64 的符号位/指数/尾数拆解与完整二进制、十六进制。
3
对比「实际存储值」与输入值的误差，理解精度丢失。

计算示例

例 1示例 1：0.1 的双精度

0.1 存成 float64 是 0x3FB999999999999A，实际值 0.1000000000000000055511151231257827——比 0.1 大了一点点，累加误差由此而来。

例 2示例 2：单精度误差更大

0.1 的 float32 是 0x3DCCCCCD，实际值 0.100000001490116，误差 1.49e-9——float32 只有约 7 位十进制有效数字，金额计算禁用。

注意事项

float64 有效精度约 15–17 位十进制，float32 只有 6–8 位；超过 2^53 的整数在 double 里也无法精确表示。
特殊值编码：指数全 0 尾数全 0 是 ±0；指数全 1 尾数全 0 是 ±Infinity；指数全 1 尾数非 0 是 NaN。
比较两个浮点数应使用 |a−b| < 1e-9 这类容差判断，而不是 a === b。
金额场景的正确做法：以「分」为单位用整数存储，或使用 BigDecimal/decimal.js 这类十进制库。

常见问题