java类型转换本质是二进制位的重新解释：自动转换仅按类型容量安全扩容，强制转换直接截取低位并重解释，不校验越界；需紧盯升/截/精度丢失三环节，用math.tointexact等主动防御溢出与精度风险。
Java类型转换不是写对括号就完事，而是数据在二进制层面被重新解释的过程。自动转换只走安全扩容路径，强制转换则完全不校验值是否越界——错误结果静默出现，调试时很难溯源。真正避坑，得从底层机制出发，盯住三件事：谁升谁、怎么截、哪里丢精度。
自动转换只认“容量大小”，不看实际数值
编译器判断能否自动转换，只比类型能表示的范围（capacity），不看当前变量存的是不是小数。比如 long → float 是允许的，因为 float 的指数范围更大；但 9223372036854775807L（Long.MAX_VALUE）转成 float 后变成 9.223372E18，末尾整数精度已丢失——这不是bug，是设计如此。
- 合法自动路径只有两条主线：byte/short/char → int → long → float → double，且 char 虽无符号，运算中一律先升为 int
- 两个 byte 相加，结果一定是 int：byte b1 = 1, b2 = 2; int sum = b1 + b2; —— 想存回 byte 必须显式 (byte)(b1 + b2)
- 整数字面量默认是 int，小数默认是 double：short s = 10; s = s + 1; 编译失败，因为 s+1 中的 1 是 int，整个表达式是 int 类型
强制转换本质是“位截取”，不是“数值缩放”
写 (byte)1500 不是让 JVM 把 1500 “压”进 byte 范围，而是直接取 1500 的 32 位二进制低 8 位，按 byte 的补码规则解释。1500 的二进制低 8 位是 11001100，作为 signed byte 就是 -52（不是 -56，因 1500 % 256 = 148，148 - 256 = -108？不对——实际计算：1500 的十六进制是 0x5DC，低 8 位是 0xDC = 220，220 - 256 = -36？再核：1500 ÷ 256 = 5 余 220，220 的二进制 11011100，最高位 1 表示负，反码+1 得 -36。但常见例子用 200：200 的低 8 位是 11001000，即 -56。关键点在于：它不做任何数学映射，只取位、重解释。
- double → int 永远截断小数，不是四舍五入：(int)3.9 得 3，(int)-3.9 得 -3
- char → byte 可能变负：char c = 200; byte b = (byte)c; 结果是 -56，因 char 是 0~65535，而 byte 是 -128~127
- long → int 若超范围，只留低 32 位：0x123456789L 强转 int 得 0x56789（即 354249）
精度丢失和溢出风险必须主动防御
Java 不会在强制转换时抛异常或警告，所有风险都由开发者兜底。靠经验猜范围不如代码里加一层防护。
- 用 Math.toIntExact(long) 替代 (int)long：超出 int 范围时抛 ArithmeticException，而非静默错值
- 浮点转整前先做逻辑判断：if (d >= Integer.MIN_VALUE && d
- 涉及 byte/short 存储时，明确校验：if (value >= -128 && value
boolean 和字符串不属于类型转换范畴
boolean 与任何数值类型之间禁止自动或强制转换——这不是限制，而是类型系统的设计原则。true/false 不是 1/0，这是 Java 明确切断的歧义链。String 与其他类型互转（如 Integer.parseInt、String.valueOf）属于解析/格式化操作，不触发 JVM 的类型转换机制，也不会有 ClassCastException，但可能抛 NumberFormatException。
- 不能写 if ((int)true == 1)，会编译报错
- 不能用 (String) new Object()，编译期直接拒绝；向下转型 Object → String 必须 instanceof 预检，否则运行时 ClassCastException
- “123”转 int 失败是业务异常，和类型转换机制无关，别混为一谈
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
