Java Socket自定义协议需用定长消息头（含length、type、version）标识消息边界，避免粘包拆包；消息体应为UTF-8字符串或Protobuf等序列化数据，整体作为不可分割块；Socket层须手动循环读取确保读满头和体。
在 Java Socket 编程中设计自定义协议，核心是让接收方能准确识别一条完整消息的起始和结束。这必须靠结构化的消息头（Header）与消息体（Body）配合实现，否则会遇到粘包、拆包问题——比如连续发两条“hello”和“world”，服务端可能只收到“helloworld”这一串字节，无法区分边界。
消息头必须包含长度字段或分隔符
最常用且健壮的方式是用定长消息头携带消息体长度。例如：前 4 字节为 int 类型的 body 长度（网络字节序），紧随其后是真实数据。这样接收方先读够 4 字节，解析出长度 L，再精确读取 L 字节，就拿到了完整消息体。避免依赖换行符（如 \r\n）做分隔，因为业务数据本身可能含该字符，导致误截断。
- 消息格式示例：4 字节 length + 1 字节 type + N 字节 body
- 发送时用
DataOutputStream.writeInt()写长度，确保字节序统一 - 接收时用
DataInputStream.readInt()读长度，再循环读满 body
消息头里建议预留类型和版本字段
仅靠长度还不够。加 1 字节消息类型（如 MessageType.LOGIN = 1），服务端可快速路由到对应处理器；再加 1 字节协议版本号（如 version = 1），后续扩展字段或调整格式时，老客户端仍能被兼容识别或拒绝，不导致解析崩溃。
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 典型头结构（共 6 字节）：length(int,4) + type(byte,1) + version(byte,1)
- type 和 version 值必须客户端与服务端严格一致，建议定义公共接口常量
- 版本号不升级时，新服务端可对旧版本请求做适配逻辑，而非直接报错
消息体用标准编码并避免隐式结构
消息体是纯业务数据，推荐用 UTF-8 编码的字符串或结构化二进制（如 Protobuf 序列化结果）。不要在 body 里再嵌套类似“\r\n”或“|”分隔的文本结构——这会让解析逻辑变重、易出错。如果需多字段，应在序列化阶段处理好（如 JSON 字符串或自定义二进制字段排列），body 整体视为一个不可分割的数据块。
立即学习“Java免费学习笔记（深入）”；
- 发送前：将用户 ID、内容等组装成对象 → 转 JSON 字符串 →
getBytes(StandardCharsets.UTF_8) - 接收后：按 header 中 length 读完 body → new String(bytes, UTF_8) → JSON 反序列化
- 不推荐：body 内用冒号拼接 “21:hello”，因用户名或内容本身可能含冒号
Socket 层需配合流式读取逻辑
Java 的 InputStream 是阻塞式字节流，没有“自动按包读”的能力。你必须自己封装读取方法：先确保读满 header（如 6 字节），再根据 length 读满 body。不能直接用 BufferedReader.readLine()，它依赖换行符且内部有缓冲，会破坏自定义协议边界。
- 关键动作：每次读操作前检查
available()不可靠，应使用循环read(byte[], off, len)直到读够 - 推荐封装工具类，如
readFully(InputStream, byte[], offset, length) - Netty 用户可用
LengthFieldBasedFrameDecoder自动完成拆包，底层原理相同
