float精度瓶颈在于其23位尾数（含隐含1位共24位二进制），仅能精确表示≤2²⁴=16777216的整数，超出后因有效数字仅6–7位十进制而发生不可逆舍入截断。

因为 float 的有效精度只有约 6～7 位十进制数字，而 long 最多能表示 19 位数字。即使 long 值在 float 的数值范围内，只要它超出 float 能精确表达的整数上限（2²⁴ = 16,777,216），低位数字就会被舍入或截断。

float 的精度瓶颈在哪？

float 是 32 位 IEEE 754 单精度浮点数，其中：

• 1 位符号位
• 8 位指数位（决定范围）
• 23 位尾数位（决定精度）

实际可表示的整数精度上限是 2²⁴（即 16,777,216）。超过这个值后，相邻两个可精确表示的整数之间会出现间隔。例如：

• 16777215 和 16777216 都能精确表示
• 16777217 就无法精确表示，会被四舍五入为 16777216 或 16777220

long 值越大，丢失越明显

一个典型的 long 值如 1234567890123L，共 13 位数字，远超 float 的 7 位有效精度。转换后结果可能变成 1.23456794E12 —— 尾部数字已失真。

负数同理，比如 -1234567890123L 转成 float 后也可能显示为 -1.23456794E12，原始精度已不可逆丢失。

为什么编译器还允许自动转换？

Java 的“宽化转换”只看数值范围是否覆盖，不检查精度：

• float 最大值约 ±3.4×10³⁸，远大于 long 的 ±9.2×10¹⁸
• 所以从“能否表示”角度看，转换合法；但从“能否准确还原”角度看，它不安全

怎么避免这类问题？

关键看使用场景：

• 做科学计算、允许近似：用 double 替代 float（double 有 53 位尾数，可精确表示所有 ≤ 2⁵³ ≈ 9×10¹⁵ 的 long）
• 做金额、ID、计数等需严格保真的场景：避免转 float/double，优先用 long 本身，或改用 BigDecimal
• 必须转且需验证：可用 (long) floatValue == originalLong 判断是否丢失（但仅适用于小值）