Java类型转换是数据清洗稳定性和准确性的底层支撑，需在自动转换、强制转换、类型契约和日志处理中严格遵循范围校验、精度保留与异常捕获原则。
Java 类型转换逻辑不是语法细节，而是数据清洗流程中稳定性和准确性的底层支撑。尤其在自动化工作流里，类型误判会直接导致字段截断、数值溢出或解析中断——比如把用户手机号（字符串）误当 int 解析后强转 byte，结果变成负数；又或日志时间戳用 double 读入再 (int) 强转，小数部分被直接丢弃，精度全失。
清洗阶段：用自动转换简化安全赋值
在解析原始日志字段时，若确认源值范围安全，可依赖 Java 自动类型提升减少冗余代码。例如从 CSV 读取年龄字段（文本型），先 parse 成 int，再赋给 short 或 long 变量——只要原始值在 -128~127 内，直接 short age = Integer.parseInt(strAge) 即可，无需显式 (short)。但注意：char、byte、short 之间不支持直接运算，混合出现时 JVM 会统一提升为 int，所以 byte a = 10, b = 20; int sum = a + b; 合法，而 byte sum = a + b; 编译报错，必须加 (byte) 显式回转。
转换阶段：强制转换前必做范围校验
当需将大类型压缩存储（如 long 用户 ID 转为 int 以适配旧表结构），或浮点统计值转整型计数时，强制转换是必要操作，但绝不能裸写 (int)。建议封装校验逻辑：
- 对整型：用 Math.toIntExact(longValue) 替代 (int)，它会在溢出时抛 ArithmeticException，便于捕获并打标异常记录
- 对浮点：(int) x 是截断，Math.round(x) 才是四舍五入；若需保留小数位，应使用 BigDecimal.setScale()，避免 double 精度丢失
- 对字符串数字：Integer.parseInt() 比 Integer.valueOf() 更适合清洗场景，因前者抛 NumberFormatException 可明确区分空值、格式错误、超界三类问题
工作流编排中的类型契约设计
可视化 ETL 工具（如助睿 Uniplore）虽屏蔽底层代码，但其字段类型定义仍受 Java 类型系统约束。例如配置“手机号清洗”节点时，若上游输出为 String，下游期望 int，则工具内部实际调用的就是类似 cleanPhone() 的 Java 方法——先正则过滤非数字，再判断长度是否为 11，最后尝试 Long.parseLong() 并 catch 异常。因此，在拖拽构建清洗管道前，应预先约定各环节的类型契约：输入字段类型、允许的空值标识（如 “-”、“NULL”）、目标类型及容错策略（跳过/填默认值/报错中断）。这比事后调试类型 mismatch 错误高效得多。
立即学习“Java免费学习笔记（深入）”；
日志与指标场景下的典型踩坑点
千万级行为日志清洗中，常见类型陷阱包括：
- 时间字段混用：日志里 “2026-06-23 09:15:22” 是 String，直接 parseLong 会失败；正确路径是先用 DateTimeFormatter 解析为 Instant，再 toEpochMilli()
- 布尔值泛化：原始日志用 “1/0”、“Y/N”、“true/false” 表示开关状态，不可直接 Boolean.parseBoolean() —— 它对 “1” 返回 false；应统一映射字典再转 boolean
- 金额精度丢失：用 float 存交易金额，哪怕只做加法也会累积误差；清洗环节必须用 BigDecimal 或 long（单位：分）处理
