JVM类型转换本质是二进制块的重新解释，由字节码指令驱动：数值转换依位宽与可表示范围严格升降（如int→long符号扩展、long→int截断），运算前小类型强制提升为int，引用转换依赖运行时checkcast验证实际类型。
Java 类型转换的核心逻辑，不在于语法糖或编译器“聪明”，而根植于 JVM 的运行时语义和内存模型。它不是孤立的语言特性，而是与 JVM 如何组织数据、解释字节码、管理栈帧紧密耦合的底层行为。
类型转换本质是二进制的重新解释
JVM 不关心“int”或“double”的名字，只处理 32 位或 64 位的二进制块。自动转换（如 int → long）实际是：把 4 字节 int 的符号位扩展复制到高位，补成 8 字节；强制转换（如 long → int）则是直接截断高 4 字节，保留低 4 字节——数值可能突变，但 JVM 按规则执行，不校验合理性。
- 所有数值类型转换都发生在操作数栈或局部变量表中，由字节码指令（如
i2l、f2d）明确驱动 - char 转 int 是无符号扩展（0~65535 映射到 0~65535），而 byte 转 int 是有符号扩展（-128~127 映射到 -128~127），这在字节码层面由不同指令区分
- boolean 完全不参与转换，JVM 规范禁止生成任何涉及 boolean 的转换字节码，它只用于条件跳转（
ifne、ifeq等）
运算提升由 JVM 栈帧结构决定
为什么 byte a = 1; byte b = 2; byte c = (byte)(a + b); 必须强转？因为 JVM 在执行加法前，会把 a、b 从局部变量表加载到操作数栈，并**强制提升为 int**——这是字节码规范硬性要求，不是 Java 语言层的妥协。栈中只有 int 类型的加法指令（iadd），没有 byte 加法指令。
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 所有小于 int 的整数类型（byte、short、char）参与算术运算时，一律先提升为 int
- 表达式结果类型取决于操作数中“最宽”类型：int + float → float，long + double → double
- 这种提升发生在字节码生成阶段，由编译器根据 JVM 指令集约束插入对应转换指令（如
i2f）
引用类型转换依赖运行时类型信息
对象类型转换（如 Object o = new String(); String s = (String) o;）能否成功，不在编译期决定，而由 JVM 在执行 checkcast 字节码时，查证堆中对象的实际类是否属于目标类型或其子类。这依赖于方法区中已加载的类元数据和对象头中的 klass 指针。
立即学习“Java免费学习笔记（深入）”；
- 向上转型（父类引用指向子类对象）无需检查，是安全的，字节码中甚至不生成
checkcast - 向下转型必须经
checkcast指令验证，失败抛ClassCastException，这是 JVM 运行时安全机制的一部分 - 泛型擦除后，类型转换仅作用于原始类型，JVM 不感知泛型参数，所以
List<string></string>和List<integer></integer>在运行时都是List
自动转换边界由 JVM 内存布局锚定
为什么 int 可以自动转 double，但 double 不行？因为 JVM 中 double 占 64 位，能精确表示所有 32 位 int 的值（2³² 个整数都在 double 的可精确表示范围内）；反之，double 有 2⁵³ 个可精确整数，远超 int 的 2³²，截断必然丢失精度。这个判断依据，来自各类型在 JVM 运行时数据区中定义的位宽与数学表达能力。
- 自动转换路径（byte→short→int→long→float→double）严格按位宽和可表示范围单调递增排列
- JVM 不允许跨类型族转换，例如 char 和 byte 都是 16 位和 8 位，但 char 是无符号，byte 是有符号，二者不兼容，无自动路径
- 所有自动转换保证数值不变（除浮点数固有精度限制外），这是 JVM 规范对“安全性”的承诺，也是编译器敢于在编译期插入转换指令的前提
