强制类型转换无法解决浮点数精度问题，因0.1和0.2在二进制中本就不能精确表示；真正有效方案是用long处理整数单位或BigDecimal（仅接受String构造）并避免==比较。
强制类型转换不能解决 float 与 double 的精度截断问题，反而可能掩盖或加剧误差。 它只是把一个不精确的值，用另一种不精确的方式重新解释，不会恢复丢失的十进制精度。
为什么 (float)0.1f + (double)0.2 仍输出 0.30000000000000004
根本原因不是类型不一致，而是 0.1 和 0.2 在二进制中本就不能被有限位数精确表示。无论你把它存成 float 还是 double，只要字面量是十进制小数，JVM 就会先按 IEEE 754 规则将其转为最接近的二进制浮点近似值——这个过程在字面量解析阶段就已完成，强制转换毫无作用。
常见错误现象：
-
System.out.println((double)(float)0.1f + 0.2);输出仍是0.30000000000000004 -
float f = (float)0.1; double d = f + 0.2;结果和0.1 + 0.2完全一样
哪些操作看似“修复”实则误导
有人尝试用格式化、截断、四舍五入来“掩盖”误差，但这只是视觉欺骗，不是精度修复：
-
String.format("%.1f", 0.1 + 0.2)→ 输出"0.3"，但底层值仍是0.30000000000000004 -
(int)((0.1 + 0.2) * 10)→ 得到3，但若换成0.15 + 0.25，可能因误差变成3.9999999999999996，(int)截断后变3而非4 -
Math.round((0.1 + 0.2) * 10) / 10.0看似安全，但在边界值（如0.49999999999999994）上仍可能出错
真正有效的替代路径
必须跳出“用 float/double 表示小数再修”的思维：
- 金融/计费类场景：统一用
long存“分”，例如1050L表示 10.50 元，所有加减乘除都在整数域完成 - 需要小数逻辑又无法改存储单位：必须用
BigDecimal，且只接受String构造，例如new BigDecimal("0.1")；绝对避免new BigDecimal(0.1)或BigDecimal.valueOf(0.1)（后者内部仍走Double.toString()，有风险） - 比较两个浮点结果是否“相等”：不用
==，改用Math.abs(a - b) ，但仅限于误差可容忍的场景（如图形坐标、传感器滤波），不可用于金额判定
最容易被忽略的细节
很多人以为把 float 强转成 double 就能“提升精度”，其实只是扩展了尾数位宽，原有误差照单全收——(double)0.1f 不等于 0.1，它等于 0.10000000149011612（因为 float 本身已失真）。真正要控制精度，得从源头掐断：输入即字符串，运算即 BigDecimal，输出即显式 setScale(..., RoundingMode)。任何中间环节混入原始浮点字面量，整条链就不可信。
