java中byte转int默认符号扩展，导致0x95变为-107而非149；若需无符号值，应使用b & 0xff实现零扩展，尤其在解析协议、文件头等二进制数据时。
Java 强制类型转换本身不改变二进制位，但后续参与运算时的符号扩展会实质性改变计算逻辑——真正出问题的不是“怎么转”，而是“转完怎么用”。
byte 转 int 时的符号扩展是默认行为，不是 bug
Java 的 byte 是有符号 8 位类型（-128 ~ +127）。当它被用于算术表达式（如加法、位移）时，JVM 会自动提升为 int，并执行符号扩展：用最高位（第 7 位）重复填充高 24 位。
-
(byte)0x95实际存储为 -107（因 149 > 127，补码解释为负数） - 该值提升为 int 后变成
0xFFFFFF95（即 -107 的 32 位补码），而非期望的0x00000095（149） - 这种偏差在组合多字节整数、做位运算或比较时直接导致结果错误
关键判断：你是否把 byte 当作“原始字节”使用
如果只是存数组、写文件、调用 OutputStream.write() 等 API，byte 的二进制值没变，无需干预；一旦进入算术上下文，就必须处理符号位干扰。
Java JDK 25
下载
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
- 错误信号：正数输入却得到负数中间结果；多个不同 int 值转成同一 byte 后，在后续计算中表现一致
- 典型场景：解析网络协议头、读取图像/音频文件头、还原 IP 地址或时间戳等二进制结构
- 验证方法：
byte b = (byte)0x95;打印b、(int)b和b & 0xFF—— 三者分别输出 -107、-107、149
修复核心：用 & 0xFF 实现零扩展
& 0xFF 不是“修复转换”，而是对已发生的符号扩展做截断：保留低 8 位，清零高 24 位，等效于无符号 reinterpret。
- 错误写法：
int n = bytes[0] + (bytes[1] → 若 <code>bytes[0]是0x95，实际加的是 -107 - 正确写法：
int n = (bytes[0] & 0xFF) | ((bytes[1] & 0xFF) - 替代方案：
Byte.toUnsignedInt(b)（Java 8+），语义更清晰，效果等价
排查陷阱链：从隐式提升开始逐层拆解
符号扩展的影响常跨多层表达式传播。调试时不能只看单个变量，要还原 JVM 实际执行的 int 运算。
- 写出完整表达式，把每个
byte替换为其符号扩展后的int值再手动计算 - 例如：
byte b = (byte)0x95; int x = b + 0x100;→ 实际是-107 + 256 = 149，而非149 + 256 = 405 - 比较逻辑易错：
if (b > 128)永远为 false（b最大是 127），应写成if ((b & 0xFF) > 128) - 日志建议：同时打印
b、(int)b、b & 0xFF，对比差异定位污染点
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
