Netty群发靠ChannelGroup统一管理在线连接，需全局唯一、连接时加入断开时移除，并结合channelUnregistered/channelInactive/exceptionCaught可靠监听下线，用LengthFieldBasedFrameDecoder防粘包，系统消息与用户消息应分离编解码。
怎么让多个客户端共享同一个 ChannelGroup 实现群发
Netty 里群发不是靠手动遍历所有 Channel，而是用 ChannelGroup 统一管理在线连接。它本质是个线程安全的集合，支持广播（writeAndFlush）时自动跳过不可写或已关闭的 channel，省去手动判空和异常捕获。
关键点在于：必须在连接建立时就加入 group，断开时立刻移除；group 实例要全局唯一（推荐用 static final ChannelGroup 或 Spring 管理的 bean），否则不同 handler 拿到的不是同一组。
-
ChannelGroup不是自动清理的——哪怕 channel 异常断开，也要靠handlerRemoved或exceptionCaught主动调用remove() - 别在
channelRead里直接对ChannelGroup调用writeAndFlush后再处理业务逻辑，可能因异步导致状态错乱；建议先构造消息，再统一广播 - 如果用了
SimpleChannelInboundHandler，注意它默认会自动释放ByteBuf，广播前得retain()一次，否则其他 channel 收到的是已释放内存，表现为收空或报IllegalReferenceCountException
客户端下线时如何可靠触发通知逻辑
“客户端关掉窗口就消失”这事 Netty 不会自动告诉你，必须自己监听连接生命周期事件。最常见误区是只重写 channelInactive，但这个方法不一定被调用（比如网络闪断、TCP RST、kill -9 进程），真正可靠的入口是 channelUnregistered + channelInactive + exceptionCaught 三者组合。
通知本身不能只发一次字符串，要带上下线用户标识（比如登录时分配的 userId 或 name），否则群聊里没人知道谁走了。
- 别在
channelInactive里直接调用ChannelGroup.writeAndFlush发下线通知——此时 channel 可能还没从 group 移除，广播会把自己也包含进去 - 用户标识必须在登录认证成功后绑定到
Channel的attr()上，例如：ctx.channel().attr(ATTR_USER_ID).set(userId)；不要存在局部变量或 Map 里，否则 GC 或并发时容易丢失 - 如果用了心跳机制（
IdleStateHandler），超时触发的userEventTriggered也是下线信号源之一，漏掉会导致“假在线”
怎么避免粘包/半包导致消息解析失败
聊天室里用户随手敲一行字，底层 TCP 可能拆成两段发，也可能把两条消息拼一起——不处理粘包，JSON.decode 就会抛 MalformedJsonException，或者只读到半个对象。
Netty 自带的 LineBasedFrameDecoder 和 DelimiterBasedFrameDecoder 太弱，适合简单协议；真实场景建议用 LengthFieldBasedFrameDecoder，按消息头里的长度字段切分。
- 发送端必须严格写入长度字段（如 4 字节 int），且和实际 body 长度一致；常见错误是忘了
writeInt(body.length)，或 body 包含中文时没按 UTF-8 字节长度算 - 解码器参数顺序很关键：
new LengthFieldBasedFrameDecoder(1024, 0, 4, 0, 4)中第三个参数是 lengthFieldOffset（长度字段起始位置），第四个是 lengthAdjustment（是否要加偏移），配错就全乱 - 别在
ChannelInboundHandler的channelRead里用toString(CharsetUtil.UTF_8)直接转整个ByteBuf——它可能只是半条消息，要等解码器输出完整帧后再处理
为什么上线通知和群聊消息要用不同的编码方式
上线通知（如 “张三加入了聊天室”）是服务端生成的系统消息，格式固定；而用户发的聊天内容是任意文本，可能含 emoji、换行、引号。混用同一种 JSON 序列化逻辑，会导致前端解析崩溃或 XSS 风险。
更实际的问题是：系统消息不需要走完整业务校验链路（比如敏感词过滤、频率限制），硬塞进同一 handler 容易耦合，出问题互相拖累。
- 建议把系统消息定义为独立 POJO（如
SystemMessage），和用户消息ChatMessage分开 encode/decode - 前端接收时通过字段（如
"type": "system"或"type": "chat"）区分，而不是靠内容特征判断 - 如果用 WebSocket，别把所有消息都塞进
TextWebSocketFrame；二进制帧（BinaryWebSocketFrame）更适合传结构化数据，减少 base64 开销
真正难的不是写通群聊，而是当 500 个客户端同时上线又断连时，ChannelGroup 的增删操作、心跳检测、消息广播之间的竞态有没有被 cover 住——这些地方没日志、没监控，问题只会悄悄堆积到某次大促才爆发。
