浮点数包装类（Float/Double）不缓存，因其取值范围过大、精度不可控且语义上不支持精确相等判断；valueOf方法每次返回新对象，是语言规范的主动设计而非缺陷。
因为浮点数的取值范围太大、精度不可控，缓存既不实用也难以设计。
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
取值范围过大，缓存性价比极低
Float 和 Double 的可表示数值范围远超整型： - Float 约为 ±3.4×10³⁸，Double 约为 ±1.8×10³⁰⁸； - 而 Integer 缓存仅覆盖 [-128, 127] 这样有限且高频的小整数区间。 即使只缓存常见小浮点数（如 0.0、1.0、-1.0），其二进制表示受 IEEE 754 规则影响，存在大量“看似相等实则位模式不同”的情况（比如 -0.0 ≠ 0.0 在某些比较中），缓存命中率低，内存开销却显著上升。
浮点数语义不支持精确相等判断
浮点运算本身存在舍入误差，两个数学上相等的表达式（如 0.1 + 0.2 和 0.3）在二进制中往往生成不同 bit 模式，导致 == 比较失败。 缓存机制依赖“值相等即对象可复用”，但浮点数缺乏可靠的值等价判定基础——连 equals() 都需谨慎使用（推荐用 Double.compare() 或误差范围判断）。强行缓存反而会掩盖精度问题，误导开发者。
装箱行为统一由 valueOf 控制，而 Float/Double 的 valueOf 不做缓存
Java 明确规定：Float.valueOf(float) 和 Double.valueOf(double) 每次都返回新对象（JDK 源码中无缓存数组或查找逻辑）； - 即使是 Double d = 1.0; 这样的自动装箱，背后调用的也是无缓存的 valueOf； - new Double(1.0) 更是强制新建，与缓存无关。 这和 Integer.valueOf(int) 中显式的 [-128,127] 判断形成鲜明对比，是语言规范层面的主动放弃，而非技术遗漏。
不复杂但容易忽略：浮点包装类没缓存，不是缺陷，而是对语义和工程实际的尊重。
