LengthFieldBasedFrameDecoder必须指定lengthFieldOffset，因其默认从第0字节读长度字段，而协议中长度字段常位于头部偏移位置（如TLV中偏移2）；offset错会导致越界或解错。
LengthFieldBasedFrameDecoder 为什么必须指定 lengthFieldOffset
不设这个偏移量，解码器根本不知道从哪开始读长度字段——它默认从包头第0个字节开始找，但真实协议里长度字段往往不在开头。比如 TLV 结构中，前2字节是类型，长度字段在第3–6字节，这时候 lengthFieldOffset 就得填 2，否则它会把类型字节当长度，直接解出错包或抛 CorruptedFrameException。
常见错误现象：java.lang.IndexOutOfBoundsException: readerIndex(2) + length(4) exceeds writerIndex(3)，本质就是 offset 算错了，导致越界读取。
-
lengthFieldOffset是“从包头起第几个字节开始是长度字段”，单位是字节，从0开始计数 - 如果长度字段本身带 header（比如前2字节是 magic，再后4字节才是 length），offset 要跳过 magic，填
2 - 若协议文档写“length 占4字节，位于报文第5–8字节”，那 offset 就是
4（因为第1字节索引是0）
lengthAdjustment 和 initialBytesToStrip 怎么配合用
这两个参数不是独立调优项，而是协同决定“最终交给业务 handler 的数据内容”。lengthAdjustment 用来修正长度字段的语义偏差，initialBytesToStrip 决定要不要砍掉协议头。
典型场景：长度字段只包含 body 长度，但整个包结构是 [header:2][length:4][body]，且 header+length 都不该传给业务逻辑。
-
lengthAdjustment = -6：因为长度字段值没算 header 和 length 自身这6字节，要减回去，让解码器按“总包长 = length字段值 + 6”截取 -
initialBytesToStrip = 6：把 header 和 length 字段一起剥掉，只留body给下一个 handler - 如果业务需要保留 header，就设
initialBytesToStrip = 0，但注意后续 handler 得自己解析 header
为什么 decode 后常收到空 ByteBuf 或抛 TooLongFrameException
空 ByteBuf 多半是 lengthFieldLength 设错导致读了全0的长度字段；TooLongFrameException 则是 maxFrameLength 设得太小，或者 length 字段被污染（比如粘包时上一个包的尾部刚好凑成合法长度值）。
真实调试中，先用 Wireshark 抓包确认长度字段的实际值和位置，再比对 Netty 配置——别信文档，信抓包。
-
lengthFieldLength必须严格匹配协议定义：2字节就用2，4字节就用4，不能靠“大概” -
maxFrameLength建议设为协议允许的最大应用层消息长度，不是 TCP MSS，设太小会误杀大包，设太大失去保护意义 - 遇到空 buf，打日志看
in.readableBytes()和实际读到的 length 值，常发现 length 字段被拆到了两个 TCP 包里，此时需确保前置有LineBasedFrameDecoder或其它基础分帧（但一般不推荐混用）
Netty 5 迁移后 LengthFieldBasedFrameDecoder 行为变化
Netty 4.1.x 中，如果 lengthFieldEndOffset 超出当前可读范围，会静默等待更多数据；而 Netty 5（即 io.netty:netty-all:5.0.0.AlphaX）改为立即抛 CorruptedFrameException，因为更早暴露问题。
这意味着：老代码在 Netty 4 下看似正常，升到 5 后大量报错，根源其实是协议实现本就不健壮——比如没处理好跨包读 length 字段的边界情况。
- 升级前务必检查 length 字段是否可能被 TCP 拆开，如果是，必须在 decoder 前加
ReplayingDecoder（Netty 4）或改用LengthFieldPrepender+ 自定义校验（Netty 5） - Netty 5 中
failFast = true已默认开启，无法关闭，所以异常会立刻冒泡，不能再靠 try-catch 吞掉 - 如果协议允许变长 length 字段（如前1字节表示长度字节数），
LengthFieldBasedFrameDecoder无能为力，得手写ByteToMessageDecoder
粘包拆包不是加个 decoder 就完事，关键在 length 字段的定位、解释和容错——这三个参数一旦配错，问题会藏得很深，直到压测时突然大批量解错或 OOM。
