不能用 NegativeArraySizeException 做校验，因为它是 JVM 底层创建负长度数组时的副作用异常，无法提前拦截、定位困难、覆盖场景不全，且违背异常使用原则；正确做法是解析长度后立即显式校验范围、防溢出、设上限并抛出语义明确的异常。
NegativeArraySizeException 本身是一个运行时异常，由 JVM 在尝试创建负长度数组时抛出（例如 new byte[-1]），它不是设计用来做完整性校验的机制，也不能主动“利用”来验证数据包长度。把它当作校验手段，属于误用，会掩盖真实问题，降低系统健壮性和可维护性。
为什么不能用 NegativeArraySizeException 做校验？
该异常是 JVM 底层行为触发的副作用，而非语义明确的校验信号：
- 它只在
new byte[xxx]等数组创建语句执行时才抛出，无法提前拦截非法值； - 一旦抛出，调用栈已深入分配逻辑，错误定位困难，且可能伴随资源泄漏（如流未关闭）；
- 负长度只是非法输入的一种情况，零长度、超大长度（溢出、超出内存限制、协议约定上限）同样危险，但不会触发此异常；
- 依赖异常流程控制业务逻辑，违背“异常用于异常情况”的原则，性能差、可读性低。
正确做法：显式长度校验 + 协议约束
应在解析长度字段后、分配缓冲区前，立即检查其有效性：
- 检查符号与范围：确认长度为非负整数，且不超过协议定义的最大合法值（如 TCP payload ≤ 65535，或自定义协议规定的 maxPayloadSize）；
- 防范整数溢出：若长度由多个字节组合（如 4 字节 big-endian int），需确认解码过程无符号截断或误解释（例如把 0xFF_FF_FF_FF 当作 -1 而非 4294967295）；
- 预留安全余量：避免刚好分配理论最大值，可设硬上限（如 ≤ 16MB），防止恶意构造超大数据包耗尽内存；
-
早失败、明错误：校验失败时抛出语义清晰的异常（如
IllegalArgumentException("invalid packet length: " + len)），并记录上下文（如数据源 IP、偏移位置）。
一个典型安全解析示例（Java）
假设从 ByteBuffer 中读取 2 字节无符号长度：
int len = (buffer.get() & 0xFF) << 8 | (buffer.get() & 0xFF); // 正确读取为 0–65535
if (len < 0 || len > MAX_PACKET_SIZE) {
throw new IllegalArgumentException("Invalid packet length: " + len);
}
byte[] payload = new byte[len]; // 此时才安全分配
buffer.get(payload);
补充建议
- 使用有界容器（如 Netty 的
ByteBuf.readableBytes()）预先确认缓冲区足够，避免越界读； - 对不可信来源（如公网 socket），始终启用长度校验，不依赖“对方应该守规矩”；
- 在单元测试中覆盖边界值：0、1、MAX_PACKET_SIZE、MAX_PACKET_SIZE+1、负数位模式（如 0xFFFF_FFFF 解码后为 -1）等。
