java中byte有符号，0xff存为-1，故b == 0xff恒不成立；正确做法是先b & 0xff转为int再比较或运算，避免符号扩展导致语义错误。
Java 中 byte 读出来是负数，if (b == 0xFF) 为什么永远不成立
因为 Java 的 byte 是有符号的，0xFF（255）存进来会变成 -1。直接用 == 比较时，-1 ≠ 255，条件自然失败。这不是 bug，是类型语义错配。
正确做法是：所有参与逻辑判断或数值计算前，先转成 int 并与 0xFF 做按位与：
-
int value = buffer.get() & 0xFF;—— 把 -1 变成 255，高位清零 -
if ((value & 0x80) != 0)—— 判断最高位是否置位，安全 - 别写
if (buffer.get() == (byte)0xFF)，这依赖字面量强制转换，掩盖本质问题 - IDE 提示“可简化为
b == -1”时，千万别点——那是把协议语义硬塞进有符号框架
C# 里该用 byte 还是 sbyte 解析网络报文
C# 的 byte 本身就是无符号（0~255），sbyte 才是有符号（-128~127）。网络字节流不需要解释为负数，所以必须统一用 byte。
常见错误包括：
- 从 socket 读到
byte[] data，却写sbyte flags = (sbyte)data[2]—— 0xFF 变成 -1，后续& 0x80得 -128 - 用
Span<sbyte></sbyte>包装原始数据，再取元素做位运算 —— 符号扩展悄悄发生 - 调用类似
Convert.ToInt32(someSbyte)后参与拼包 —— -1 变成 0xFFFFFFFF，BitConverter.ToUInt16出错
只要声明为 byte，flags & 0x01、flags 全部安全，无需额外掩码。
Go 和 Rust 为什么“看起来没这个问题”，但仍有陷阱
Go 的 byte 就是 uint8，Rust 的 u8 也是无符号，读取 buf[0] 直接就是 0~255。但这不等于高枕无忧。
容易被忽略的点：
- Go 中若写
v := int8(buf[0])，0xFF 就变成 -1；应写v := int(buf[0])或保留uint8 - Rust 中
let x = buf[0] as i8;会把 255 强转成 -1，除非你明确需要有符号解释 - 打印调试时用
fmt.Printf("%d", buf[0])没问题，但用%v配合int8变量就可能输出负值，和 Wireshark 十六进制视图对不上
跨语言联调时，Wireshark 显示的永远是无符号视角，你的日志输出也该保持一致。
什么时候做 & 0xFF？不是所有地方都要加
关键在「字节刚从网卡/文件/串口进来时」就决定它代表什么。不是等到用的时候才转，而是尽早剥离符号干扰。
推荐策略：
- Socket 读到
byte[]后，立即批量转成int[]或封装为带无符号语义的结构体字段 - ByteBuffer 读取单字节后，立刻
& 0xFF赋给int字段，别让byte变量在业务逻辑中长期存在 - 只在纯透传、不参与计算的场景（如 memcpy、base64 编码）才保留原始
byte - 图像处理中 RGB 分量、MODBUS RTU 的功能码/寄存器地址，全部按无符号处理，别等出错了再查是不是 -128
最常被忽略的不是“怎么转”，而是“在哪转”——延迟转换会让符号污染扩散到多层函数调用里，debug 成本指数上升。
