java基本类型自动转换优先级为byte→short→int→long→float→double，char与byte/short不互通；算术运算中三者均提升为int；boolean不参与数值转换；赋值缩小时仅允许编译期常量。
Java中基本类型自动转换的优先级顺序是什么
Java只允许在「数值范围不丢失」的前提下自动提升，比如 byte → short → int → long → float → double，但 char 和 byte/short 之间不自动互通（尽管它们都是16位或更小）。
常见误解是认为 char + int 会保持 char 类型，实际结果是 int —— 因为二元运算中，char 会被提升为 int 再计算：
char c = 'A'; int i = c + 1; // 合法：c 自动转为 int，结果是 66 // int j = c + 'B'; // 同样是 int，不是 char
-
byte、short、char在参与算术运算时，一律先提升为int（哪怕只是byte b = 1; b++;，内部也经历int中转） -
boolean不参与任何数值转换，和任何类型都不能自动转换，if (flag)是语法特例，不是类型转换 - 赋值时的自动转换仅发生在声明初始化阶段，且右侧必须是编译期常量才能缩小：
byte b = 100;合法，但int i = 100; byte b = i;编译失败
什么时候必须用强制转换？怎么写才安全
强制转换（cast）用于「可能丢失精度或溢出」的场景，例如从大范围类型到小范围类型，或引用类型向下转型。它不检查运行时值是否合法，全靠程序员保证。
典型不安全操作：
立即学习“Java免费学习笔记（深入）”；
int i = 300; byte b = (byte) i; // 编译通过，但结果是 44（300 % 256），不是报错
- 基本类型强制转换不会抛异常，只做低位截断：
(byte) 257→1，(short) 65537→1 - 浮点转整数直接截去小数部分，不四舍五入：
(int) 3.9→3，(int) -3.9→-3 - 引用类型强制转换（如
(String) obj）在运行时若实际类型不符，会抛ClassCastException，建议先用instanceof检查
包装类与基本类型的转换陷阱有哪些
自动装箱/拆箱（autoboxing/unboxing）看似方便，但隐藏空指针和性能问题。
最典型崩溃场景：
Integer a = null; int b = a; // 运行时报 NullPointerException，因为拆箱调用 a.intValue()
-
==比较时，小范围整数（-128 ~ 127）因缓存可能相等，超出范围则对象不同：Integer i1 = 127; Integer i2 = 127; i1 == i2为true；但i1 = 128; i2 = 128;时为false - 避免在泛型集合中混用基本类型字面量和包装类做运算，比如
List<integer> list = ...; int sum = list.get(0) + 1;</integer>看似正常，但如果get(0)返回null就崩了 - 循环中频繁装箱（如
for (int i = 0; i ）会显著影响性能，可考虑用 <code>IntStream或原始类型集合库（如 Eclipse Collections）
字符串与其他类型的转换为什么不能靠强制转换
String 是引用类型，和其他类型没有继承关系，(int) "123" 这种写法根本无法编译。
必须使用解析方法，且这些方法可能抛异常：
-
Integer.parseInt("123")→int，输入非数字格式抛NumberFormatException -
Integer.valueOf("123")→Integer，同样校验格式，且对缓存范围内的值返回常量对象 -
String.valueOf(123)或123 + ""是转字符串的安全方式；但后者会隐式创建StringBuilder，高频场景建议用String.valueOf - 浮点字符串解析注意区域设置：
Double.parseDouble("3.14")在某些 Locale 下需用逗号作小数点，应显式用NumberFormat控制
类型转换不是语法糖，而是语义明确的操作。自动转换只保安全，强制转换不管死活，字符串解析必须走专用API——这三个边界划清了，多数转换问题就不会踩进坑里。
