char转int直接强转得Unicode码点，如(int)'A'为65；int转char需显式强转并确保值在0–65535内，否则低16位截断。
char转int：直接强制转换就是取ASCII码值
Java里char本质是无符号16位整数，直接赋给int或用(int)强转，得到的就是对应Unicode码点——对ASCII字符（0–127）来说，就是标准ASCII码。
常见错误现象：char c = 'A'; int i = c + 0;看似绕路，其实没问题；但有人写int i = Integer.parseInt(String.valueOf(c))，这会抛NumberFormatException，因为'A'不是数字字符串。
- 正确做法就是
(int) c，不涉及任何方法调用，零开销 - 注意：
char范围是0–65535，转int不会溢出，但若后续做算术（比如加减），要自己判断是否越界 - 别用
Character.getNumericValue()——它返回的是字符表示的“数值意义”（如'5'→5，'A'→10），不是ASCII码
int转char：强转需确保值在合法范围内
int转char必须显式强转(char)，且JVM不做范围检查——值超出char的0–65535范围时，会静默截断低16位，结果不可预测。
使用场景：生成控制字符、构造特殊符号、解析二进制协议中的字符字段。
立即学习“Java免费学习笔记（深入）”；
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 安全做法：先判断
if (i >= 0 && i 再转，否则抛<code>IllegalArgumentException - 典型坑：
int i = 256; char c = (char) i;→ 得到'u0100'（不是' '），因为256的低16位就是256 - ASCII字符只需关注0–127，但强转本身不限于这个范围；Java没有“ASCII专用char类型”，只有
char和Unicode语义
为什么(char)0和(int)'\0'都等于0，但语义完全不同
底层逻辑就一条：Java虚拟机把char当作无符号整数存储，所有转换都是按位复制+类型解释，不查表、不调用API、不触发GC。
性能影响几乎为零——这些转换编译后就是一条CPU指令（如x86的movzx）。
-
(char)0是把整数0解释为一个char值，即空字符'u0000' -
(int)' '是把空字符的位模式当整数读，结果也是0 - 但
' '和0在方法重载中可能匹配不同签名，例如foo(char)vsfoo(int)，这时类型信息决定调用哪个
String.charAt()返回char，想转ASCII码？别忘了索引边界
这是实际编码中最容易漏掉检查的一环：拿到char之后转int很简单，但String.charAt(i)本身可能抛StringIndexOutOfBoundsException。
常见错误现象：循环遍历字符串时用i ，导致越界访问，而不是<code>i 。
- 推荐写法：
for (int i = 0; i - 如果字符串含代理对（surrogate pair，如某些emoji），
charAt()只返回高位或低位char，不能代表完整字符——这时应改用codePointAt()并配合Character.isSurrogatePair() - ASCII场景下基本不用考虑代理对，但一旦输入来源不可控（比如用户昵称、日志内容），就得留心
强转本身没陷阱，陷阱都在你没检查的地方——比如索引、范围、字符集假设。
