float转double不会提升精度，只是扩展存储格式；应通过BigDecimal.valueOf(f)查看真实值，避免用new BigDecimal(f)；浮点比较须用容差，金融等场景应源头使用BigDecimal或DECIMAL。
直接把 float 强转成 double 不会报错，但结果不是“更准”，而是把原本就失真的 float 值原封不动扩展成 double 格式——误差没被修复，只是被掩盖了。排查这类精度偏离，关键不是看转换动作本身，而是看它是否在后续逻辑中暴露为错误行为。
确认 float 原值是否已失真
float 只有 23 位尾数，能精确表示的十进制小数非常有限。例如 float f = 12.8f，实际存储的是 12.800000190734863 这类近似值。用 Float.toHexString(f) 或 new BigDecimal(Float.toString(f)) 可直观看到真实值。
-
推荐做法：用
BigDecimal.valueOf(f)（内部调用Float.toString()）查看 float 的真实十进制含义 -
避免做法：用
new BigDecimal(f)—— 它先将 float 转为 double 再构造，会引入二次误差
检查 double 接收后是否参与相等判断或边界比较
这是最易暴露问题的场景。比如 float f = 12.8f; double d = f;，然后写 if (d == 12.8)，结果恒为 false。因为 12.8 在 double 中是精确可表的，但 d 存的是 float 版本的近似值。
- 所有
==、!=对浮点数都应替换为带容差的比较，如Math.abs(d - 12.8) - 若用于 switch、Map key、Set 元素等依赖精确相等的结构，必须改用字符串或整数标识
验证是否误以为“升精度=恢复精度”
double 虽有 52 位尾数，但无法凭空还原 float 已丢失的那 29 位信息。常见误判包括：
- 认为
double d = f后再String.format("%.1f", d)就能稳定输出"12.8"—— 实际可能输出"12.8"或"12.9"，取决于原始 float 的舍入方向 - 把 float 时间戳、传感器读数转 double 后做微秒级差值计算，结果偏差放大
- 在金融字段中用
double price = (double) rs.getFloat("price")，后续乘以 100 取整时出错
替代方案：从源头规避 float 失真
如果业务需要高保真小数（如配置值、金额、坐标），不要让 float 成为中间载体：
- 数据库字段用
DECIMAL或NUMERIC，Java 端用BigDecimal直接读取字符串 - 配置文件里存
"12.8"字符串，而不是12.8f字面量 - 必须用 float 输入时，立即转成
BigDecimal.valueOf(Float.toString(f))，再转 double（如有必要）
