Java的类型转换，无论是自动提升（拓宽转换）还是强制向下转（缩窄转换），从JDK 5到JDK 21，核心规则始终保持不变。简单来说：小类型转大类型，编译器自动处理；大类型转小类型，必须显式声明强制转换，且需做好精度丢失甚至溢出的心理准备。不同版本之间的差异，主要体现在编译器提示的友好度、警告覆盖范围，以及泛型、自动装箱等边界行为上的优化与微调。
接下来讨论实际开发中的体会。尽管核心逻辑未变，但在日常编码中，不同JDK版本下确实能感受到一些细微差别，尤其是在IDE和编译器的反馈方面。
自动转换中的字面量类型推断更严格（JDK 7+）
- 例如写入
byte b = 10;这种代码，在任何JDK版本中都是合法的，因为10是编译期可确定的常量，且在byte范围内。 - 但如果误写成
byte b = 128;，从JDK 1开始就是编译错误。区别在于，JDK 8及以后的编译器错误提示更加明确：incompatible types: possible lossy conversion from int to byte。关键在于“lossy”（有损）一词，而早期版本仅显示模糊的“cannot convert int to byte”。
表达式中整数字面量默认仍是 int，但编译器警告更智能（JDK 9+）
- 像
short s = 1 + 2;这样的表达式，仍然编译不通过，因为1+2的结果被视为int，无法直接赋值给short。正确做法是使用short s = (short)(1 + 2);，或者利用常量折叠直接写short s = 3;。 - 到了JDK 10+，如果使用
-Xlint:all编译参数，javac会对可能溢出或隐式截断的场景给出更详细的警告。例如int i = Integer.MAX_VALUE; byte b = (byte) i;这样的代码，它会提示warning: [cast] redundant cast to byte或possible loss of precision。本质上是在帮助开发者识别那些“写了强制转换，但可能根本没意识到风险”的代码。
泛型与自动装箱/拆箱带来的间接影响（JDK 5 引入，JDK 9+ 更严谨）
- 例如，
List在JDK 5到8中，如果误写成list = Arrays.asList((byte)1, (byte)2); Arrays.asList(1, 2)，得到的是List，随后尝试强转为List，只能在运行时抛出ClassCastException。 - 而在JDK 9及以上版本，
List.of(1, 2)这样的工厂方法会直接拒绝混合类型，在编译阶段就报错。这虽然不是类型转换规则本身发生了变化，但确实减少了因自动装箱引发的隐式转换误用，使问题更早暴露。
字符串拼接与数值转换的隐式行为（JDK 9+ 运行时优化，不影响语义）
"a" + 128的结果始终是String类型，不会触发数值类型转换。- 而
String.valueOf((byte)128)这种写法，在JDK 8和JDK 17中结果均为"-128"（因为128超出byte范围，按补码解释）。行为完全一致。版本差异仅体现在底层StringBuilder的实现或JIT优化路径上，对开发者完全透明。
boolean 类型始终不可转换（全版本统一）
- 从第一版Java开始，
boolean就禁止与任何数值类型互相转换。像if (b == 1)或(int)flag这样的写法，在任何JDK版本下都是编译错误。这条规则从未改变。
总之，Java类型转换的“契约”由JLS第5.1至5.5节定义，Oracle公司高度重视向后兼容性。所谓的“细微差别”，其更重要的意义在于：
- 编译器给出的诊断信息是否更加友好、直击要害。
- IDE（如IntelliJ或Eclipse）对危险强制转换的实时高亮和警告强度是否更智能。
javac在不同的-source模式下，对某些边缘语法的容错度有所差异（但这很少影响基本转换规则）。
因此，真正需要关注的重点并非JDK版本本身，而是：是否开启了 -Xlint:all 以捕捉潜在风险？是否在使用Lombok等可能干扰类型推断的注解处理器？以及，是否混淆了基本类型转换与包装类的拆箱操作（例如 Integer → int）？后者是拆箱，并非强制类型转换。
