Java自动类型转换是编译期静态推导，仅限兼容基本类型且范围不缩小；基础库函数是运行期契约式封装，通过签名、异常和文档明确语义。二者责任主体不同：编译器解释自动转换，调用方解释库函数。
Java 自动类型转换机制和基础库函数设计范式，表面看都服务于“让代码更简洁”，但底层逻辑完全不同：前者是编译器在类型安全前提下做的静态推导，后者是开发者基于契约与可维护性主动构建的抽象层。理解二者差异，能避免把“自动转换”当成“通用适配”，也能看清为何 Integer.parseInt() 不会、也不能自动处理空字符串或 null。
自动类型转换：编译期的确定性提升
它只发生在基本类型之间，且必须满足两个硬性条件：类型兼容 + 目标范围 ≥ 源范围。编译器不做任何逻辑判断，只做字节容量映射。
- byte、short、char 在参与算术运算时，一律先提升为 int（哪怕结果仍在 byte 范围内），这是 JVM 规范强制要求，不是优化选择
- int + long → long；int + float → float；只要表达式中出现 float，整个运算就按 float 精度执行，不保留整数部分的“精确感”
- 方法参数匹配时，只认类型层级，不认语义。传 short 给接收 int 的方法可以，但传 String 给接收 Object 的方法——那是多态，不是类型转换
基础库函数：运行期的契约式封装
像 String.valueOf()、Integer.parseInt() 这类方法，本质是人工定义的转换协议，它们不改变 Java 类型系统规则，而是用明确的输入/输出约定替代隐式行为。
-
String.valueOf(null)返回字符串 "null"，而Integer.toString(null)编译不通过——因为后者参数类型是 int，根本收不到 null；这说明库函数的签名本身就是契约的一部分 -
Double.parseDouble("1.23")成功，Double.parseDouble("abc")必抛NumberFormatException，异常是接口契约的组成部分，不是 bug - 没有
int parseInt(boolean b)，因为库设计者认定布尔值到数字的映射缺乏普适语义（true 到 1？还是 -1？），宁可让用户显式写b ? 1 : 0
关键分界点：谁承担解释责任
自动转换中，解释权完全在编译器：它知道 char c = 'A'; int i = c; 就是取 ASCII 码，无需注释。而库函数中，解释权交给调用方：你选 Long.parseLong(s, 16) 还是 Integer.decode(s)，取决于你心里对字符串格式的预设。
立即学习“Java免费学习笔记（深入）”；
- 自动转换从不抛异常——失败即编译错误，如
byte b = 128;直接报错 - 库函数大量依赖文档和异常类型传递意图，比如
Files.readAllLines()声明 throws IOException，就是在说“我不管文件在哪，但出问题你得自己兜住” - 二者叠加时最易混淆：
Double d = 10;是自动装箱 + 自动类型提升（int→double），而Double d = Double.valueOf("10");是纯库调用，中间无隐式步骤
设计启示：何时该用哪种“转换”
写业务逻辑时，优先用库函数——它把边界、异常、空值策略都摊开给你；写底层工具或性能敏感路径时，才考虑利用自动转换减少对象创建，但必须清楚每一步的精度代价。
- 需要容错或格式解析（如用户输入）→ 用
parseXxx()配 try-catch - 只是临时拓宽计算精度（如计数器累加用 long 防溢出）→ 用 int → long 自动转换，干净无副作用
- 想把 char 当数字用（如 '5' - '0' 得 5）→ 这是字符编码常识，不是类型转换，也不依赖库函数
