强制类型转换时数值变负是因截断后按补码解释所致：int转byte取低8位，超出范围则绕回，如200→-56；需用byte.tounsignedint()或b&0xff处理无符号场景；long转int静默丢高位，易致数据损坏。
强制类型转换时数值为什么突然变负数
Java里把int转成byte或short，值莫名其妙变成负的，不是bug，是截断+补码共同作用的结果。比如int x = 200;，转byte b = (byte) x;后b是-56——因为只保留低8位11001000，按byte的补码规则解释就是-56。
- Java所有整数类型都是有符号、用补码存储的，转换时不做符号扩展，只硬切二进制位
-
int → byte：取低8位；int → short：取低16位；高位直接丢弃，不四舍五入也不报错 - 如果原值超出目标类型的表示范围（如
byte是-128~127），结果必然“绕回”，类似钟表指针走一圈 - 别依赖IDE调试窗口显示的“原始值”，它可能自动做了无符号解读；用
Integer.toHexString(x)看真实二进制更可靠
什么时候该用Byte.toUnsignedInt()而不是直接强转
当你需要把byte当0~255的无符号数用（比如处理网络协议、图像像素、哈希字节流），直接强转成int会带符号扩展，0xFF变成-1，而你其实想要255。
-
(int) b：保留符号，b = -1→int还是-1 -
Byte.toUnsignedInt(b)：把b当无符号字节解释，-1（即0xFF）→255 - JDK 8+才提供
toUnsigned*系列方法；JDK 7及以前得手写(b & 0xFF)（注意必须加括号，运算符优先级坑过很多人） - 同理，
Short.toUnsignedInt(s)、Integer.toUnsignedLong(i)也适用类似场景
long转int丢失精度却不报编译错误
Java允许long → int显式强转，但编译器不检查值是否越界——运行时直接截掉高32位。比如long x = 0x123456789L;转int后只剩低32位0x23456789，高位0x1彻底消失。
- 这不是隐式转换，所以编译通过；但和
int → byte一样，属于静默数据损坏 - 如果业务逻辑依赖数值大小（比如时间戳、ID序列），这种转换极易引发诡异问题，且很难在测试中覆盖边界值
- 想安全转换，得手动判断：
if (l > Integer.MAX_VALUE || l - Lombok的
@Value或Jackson反序列化时若字段类型不匹配，也可能触发这类静默截断，得看具体配置
浮点数强转整数的舍入行为不是四舍五入
double d = 3.9;转int得3，d = -3.9;转int得-3——这是向零截断（truncation），不是四舍五入，也不是向下取整。
立即学习“Java免费学习笔记（深入）”；
-
(int) 3.9→3，(int) -3.9→-3（去掉小数部分，不看符号） - 要向下取整用
Math.floor()，四舍五入用Math.round()，但注意Math.round(double)返回long，得再转 - 浮点数本身存在精度误差，
2.000000000000001转int可能是2也可能是3，取决于二进制表示是否刚好卡在边界 - 涉及金额计算务必避免用
double强转，改用BigDecimal或整数单位（如“分”）
补码和截断是底层事实，不是Java的设计选择，而是CPU指令和内存模型决定的。很多“奇怪结果”其实是在裸露硬件逻辑——你以为在写Java，其实在和二进制打交道。
