float在移动端固定占4字节，省内存靠减少使用量和避免隐式升级；精度取决于业务场景，float仅保证6位有效数字，地图坐标需double，UI动画用float足够，金融计算须用BigDecimal/Decimal。
float 在 Android/iOS 中的内存占用是确定的：4 字节
无论你用不用，float 占 4 字节、double 占 8 字节，这是由 IEEE 754 单精度格式硬性规定的。所谓“节省内存开销”，不是靠压缩或变通存储，而是靠**减少使用数量**和**避免隐式升级**。
常见错误是写 float f = 1.23; —— 这行代码在 Java/Kotlin 中根本编译不过，因为 1.23 默认是 double 字面量，强制转换会丢失精度且触发警告；正确写法必须是 float f = 1.23f;。Swift 中同理：let f: Float = 0.1 合法，但 let f = 0.1 推导为 Double。
- Android 上大量用
float的典型场景是 OpenGL ES 渲染管线（顶点坐标、颜色值）、传感器原始数据（加速度计返回float[]） - iOS Metal 或 Core Animation 的
CATransform3D内部也全用Float，改用Double会导致 API 不兼容或运行时类型错误 - 不要为了“省内存”把本该用
int的计数器改成float——整数运算无精度损失，还更快
精度够不够，取决于你的业务场景，不是位数越多越好
float 保证 6 位有效数字，不等于“小数点后 6 位”。比如 12345678.0f 存进去实际是 12345679.0，误差已超 1；而 0.000123456f 能准确保留前 6 位（1.23456e-4），但第 7 位开始就不可靠。
真实移动端案例：
- 地图坐标（经纬度）：用
double是行业惯例，float在城市级缩放下误差可达百米级 ——float的 6 位有效数字在116.389123这种 9 位十进制数上根本撑不住 - UI 动画插值（如 alpha 从 0.0 到 1.0）：
float完全够用，0.333333f和0.3333333f对人眼无差别 - 音频采样率计算（如 44100 × 0.5f）：整数乘浮点，结果仍是整数，
float不引入额外误差
别指望 double 能“修复” float 的精度问题
换 double 只是把问题延后：它有约 15 位有效数字，但依然无法精确表示 0.1 + 0.2。iOS 上 let a: Double = 0.1; let b: Double = 0.2; print(a + b) 输出仍是 0.30000000000000004。这不是 bug，是二进制科学计数法的固有限制。
真正需要精度的场合，必须换数据类型：
- 金融计算：Android 用
BigDecimal，iOS 用NSDecimalNumber或 Swift 的Decimal - 配置参数（如“最大重试次数 3.0”这种明显是整数的浮点字面量）：直接存
int，解析时不做 float 转换 - 序列化传输：用字符串传
"22.46"，接收方再按需转Decimal或double，避开二进制表示歧义
最易被忽略的坑：混合运算与隐式类型提升
Java/Kotlin 中 float f = 1.0f; double d = f * 0.5; 看似简单，实际 f 被提升为 double 再运算，结果仍是 double —— 你声明了 float，却没真正用上它的内存优势。
更隐蔽的是函数调用：
- Android
View.setTranslationX(float)接收float，但如果你传getTranslationX() + 1.5，而getTranslationX()返回float，1.5是double，整个表达式变成double，再强转回float，多一次精度截断 - 解决方法统一加后缀：
setTranslationX(translationX + 1.5f) - 自定义工具函数别用泛型擦除：写
fun clamp(value: Float, min: Float, max: Float)，而不是fun <t : number> clamp(value: T, ...)</t>，后者可能把Float擦成Double
内存省得下来，前提是每一处数值流动都明确控制类型；精度保得住，关键不在位数，而在是否匹配业务本质——坐标要准，动画要快，钱要一分不差。
