应统一归一化浮点数文本，避免直接字符串比较或double解析比较；推荐转为固定精度整数、标准化字符串格式或使用bigdecimal（字符串构造），确保语义一致。
在集合文件查找中对浮点数文本做等值判断（比如直接用 == 或字符串 equals() 比较 "0.1" 和 "0.10000000000000001"）会导致逻辑失真，核心问题不在“文本”本身，而在于这些文本背后常被解析为浮点数参与后续计算或哈希——一旦进入 double/float 类型，原始字符串的“表意一致”就无法保障语义一致。
浮点数解析让“看起来一样”的文本变成“内存不同”的值
文件中的浮点数常以文本形式存在（如 JSON 的 "confidence": 0.95、CSV 中的 0.95 字段），但程序读取后往往调用 Double.parseDouble() 或类似方法转为 double。这个过程会触发 IEEE 754 舍入：不同来源的相同语义文本，可能因解析路径差异产生不同二进制表示。
- JSON 库解析
"0.95"→ 得到近似值 A（依赖库实现和 JVM 版本） - 数据库 JDBC 读取 DECIMAL(5,2) 字段再转 double → 得到近似值 B（经额外类型转换）
- 代码中直接写
0.95d字面量 → 得到近似值 C（编译期固化）
三者数学意义相同，但二进制位模式很可能不同。若查找逻辑依赖 == 或基于 double 的 hashCode()（如 ConcurrentHashMap），就会把同一业务含义的文件判为“不匹配”或散列到不同桶中。
字符串比较看似安全，实则掩盖更深层风险
有人试图绕过解析，直接对原始文本字符串做 equals() 比较（如比对 "0.95" 和 "0.950"）。这看似规避了浮点误差，但引入新问题：
- 格式不统一：文件可能存为
"9.5E-1"、"0.9500"、".95"，字符串层面全不等，但业务上完全等价 - 精度丢失前置：若文本来自四舍五入后的展示字段（如日志里截断到两位小数），它已不是原始值，用它反查原始数据必然漏匹配
- 无法支持范围或模糊查找：纯字符串匹配无法表达 “confidence ≥ 0.9” 这类常见过滤需求
文件元数据与哈希键生成环节最易失效
集合查找常依赖文件特征构建唯一 key，例如：
- 用
size + timestamp + score拼接后哈希，其中score是 double → 微小误差导致哈希值突变，同一文件在并发线程中被算出两个 key，分发到不同处理节点 - 按
md5(fileContent) + Math.round(confidence * 100)构建复合 key → 若 confidence 解析结果是0.8499999999999999，Math.round()变成 84；而另一处是0.8500000000000001就变成 85，key 完全不同 - 文件名含浮点数（如
report_0.95.json），程序提取后未标准化就用于路由 →"0.95".equals("0.950")为 false，路由错位
真正稳健的做法是统一归一化，而非纠结“怎么比”
关键不是选字符串还是浮点比，而是确保所有路径最终收敛到同一确定性表示：
- 读取浮点文本后，立即转为固定精度整数：如
(int) Math.round(Double.parseDouble(s) * 100)表示百分位，后续全部用 int 运算和比较 - 必须保留小数语义时，用字符串标准化：统一格式化为
String.format("%.6f", d).replaceAll("0*$", "").replaceAll("\.$", "")，再比较 - 涉及索引或分片的关键字段，改用
BigDecimal（务必用字符串构造！new BigDecimal("0.95")），并重写hashCode()和compareTo() - 配置类阈值（如
minScore: 0.95）在加载时就转为整数或BigDecimal，运行时避免任何 double 字面量参与判断
