NIO传输网络变量必须序列化并设计应用层协议处理粘包/半包，推荐长度前缀法；需用ByteBuffer手动管理缓冲、flip/compact；应封装读写工具方法；有扩展需求时优先选用Netty的LengthFieldBasedFrameDecoder。
直接用 NIO 的 SocketChannel 传输“网络变量”（比如结构化状态、配置项、传感器读数等）时，不能把变量对象直接扔进通道——必须序列化成字节流，再配合应用层协议设计来应对半包和粘包。核心不是“避免”，而是“识别边界+缓冲管理”。
明确变量数据的格式与边界规则
网络变量本身没有天然分界，必须靠协议约定。常见三种方式：
- 长度前缀法：每个变量消息开头放 2 或 4 字节大端整数，表示后续有效载荷长度（如变量名+值的总字节数）。这是最推荐的方式，健壮且无歧义。
- 固定长度法：所有变量消息统一为 128 字节（含填充）。适合字段数量/类型高度固定的场景，但浪费带宽，不灵活。
- 分隔符法：在每条变量消息末尾加特定字节（如 0x00 或 \n）。需确保变量值中不出现该分隔符，否则要转义或改用不可见控制字符。
用 ByteBuffer 正确收拢和切分变量消息
NIO 不自动拆包，你得手动维护 buffer 状态：
- 每次
channel.read(buffer)后，调用buffer.flip()进入读模式； - 按所选协议扫描 buffer：若用长度前缀，先读前 2 字节 → 得到 length → 检查
buffer.remaining() >= length + 2； - 若够长，提取完整消息（
buffer.get(new byte[length])），再buffer.compact()把剩余未读字节移到开头； - 若不够长（半包），不 compact，保留当前内容，等待下次 read 补齐；
- 严禁在未判断完整性前就
clear()，否则丢数据。
封装变量传输的读写辅助逻辑
别在业务 handler 里反复写 scan / flip / compact。建议封装两个工具方法：
- writeVariable(SocketChannel ch, String key, Object value)：将 key-value 序列化为 JSON 或二进制，加上长度头，写入 channel；
-
tryReadVariable(ByteBuffer buffer)：返回一个
Optional<byte></byte>，仅当 buffer 中存在完整变量消息时才返回其载荷字节数组，否则返回空 —— 业务层只需循环调用它，直到返回空，说明当前 buffer 已无完整变量。
优先考虑 Netty 而非裸 NIO
如果你的变量传输有持续性、可靠性或扩展需求，直接上 Netty 更省心：
- 加
LengthFieldBasedFrameDecoder(1024, 0, 4, 0, 4)：最大帧长 1024，长度字段从 offset 0 开始占 4 字节，长度字段本身不计入长度，解码后跳过这 4 字节； - 后续接自定义
SimpleChannelInboundHandler<bytebuf></bytebuf>，参数就是已剥离头、无粘连、无截断的单条变量消息； - 发送端用
ByteBuf.writeBytes(...)先写长度再写内容，Netty 自动处理 write 拆包。
