应优先选择ChannelInboundHandlerAdapter；SimpleChannelInboundHandler会自动释放消息，仅适用于只读场景，否则易致ReferenceCountException或ClassCastException。
ChannelInboundHandler 的继承选择：SimpleChannelInboundHandler vs ChannelInboundHandlerAdapter
Netty 中入站事件处理，核心是选对基类。用错会导致消息被重复释放、类型擦除异常或内存泄漏。
常见错误现象：ReferenceCountException: refCnt: 0, decrement: 1（消息被提前释放），或 ClassCastException（泛型类型不匹配）。
-
SimpleChannelInboundHandler<T>会自动释放msg（调用ReferenceCountUtil.release(msg)），**仅适用于你只读取消息、不转发或保存引用的场景**；一旦你把msg传给其他线程、缓存、或写回 channel，必须改用ChannelInboundHandlerAdapter -
ChannelInboundHandlerAdapter不动msg引用计数，完全由你控制生命周期 —— 这是更安全、更通用的选择，尤其在需要做协议拆包、聚合、或异步处理时 - 注意泛型擦除：若继承
SimpleChannelInboundHandler<ByteBuf>，但上游解码器输出的是MyPacket，运行时会直接抛ClassCastException；务必确保泛型与实际入站类型严格一致
出站事件处理的关键时机：write() vs flush() vs writeAndFlush()
出站不是“发数据就完事”，而是分阶段控制。混淆这三个操作，轻则延迟响应，重则连接卡死或 OOM。
使用场景：比如你要发送一个响应报文，但希望等前序日志落盘后再真正发出；或批量写入多个小包，需手动合并 flush 以减少系统调用。
-
ctx.write(msg)只把消息加入当前 channel 的出站缓冲队列（ChannelOutboundBuffer），**不触发实际写入 socket**；适合攒批、条件拦截 -
ctx.flush()仅刷新缓冲区，把已write的数据推到 OS socket 缓冲区；单独调用它没意义（没数据可刷） -
ctx.writeAndFlush(msg)是最常用组合，等价于write + flush；但要注意：如果 handler 在channelRead中连续调用多次writeAndFlush，每个都会触发一次系统调用，性能差 - 性能建议：高吞吐场景下，优先用
write积累，最后统一flush；或启用ChannelOption.AUTO_FLUSH（默认 true），此时write会自动 flush —— 但别在自定义 handler 里依赖它，显式控制更可靠
handlerAdded / handlerRemoved：资源绑定与清理的唯一可信入口
很多开发者把初始化逻辑塞进构造函数，或在 channelActive 里开线程池 —— 这是坑。Netty 的 handler 生命周期和 channel 生命周期不完全对齐。
容易踩的坑：handlerAdded 才是 handler 被真正添加进 pipeline 的时刻；handlerRemoved 是它被移除、且所有待处理任务完成后的最终回调 —— 唯一能安全释放资源的地方。
- 不要在构造函数中启动线程、打开文件、创建连接池；这些资源应延迟到
handlerAdded中初始化，否则可能被多个 channel 共享或泄漏 -
handlerRemoved必须关闭线程池、释放ByteBufAllocator分配的缓冲区（如持有PooledByteBufAllocator的引用）、注销 MBean —— 否则 handler 被移除后资源还在，造成内存缓慢增长 - 注意：如果 handler 被
pipeline.remove()显式移除，handlerRemoved一定会被调用；但如果 channel 关闭导致自动移除，也保证调用 —— 这是 Netty 4.1+ 的契约，可放心依赖
inbound 和 outbound 方法里的 ctx.fireXXX()：漏调或乱调会断链
自定义 handler 如果要让事件继续向 pipeline 下游传播，必须显式调用 ctx.fireXXX()（入站）或 ctx.write()/ctx.flush()（出站）。不调，事件就停在这；多调，下游收到重复事件。
典型错误：channelRead 里处理完消息后忘了 ctx.fireChannelRead(msg)，导致后续 handler（如编码器、业务 handler）收不到数据；或者在 write 中又调了一次 ctx.write()，导致消息翻倍。
- 入站方法（如
channelRead、userEventTriggered）处理完后，如需透传，必须调ctx.fireChannelRead(msg)或ctx.fireUserEventTriggered(evt)；不调 = 拦截 - 出站方法（如
write、flush）中，通常不应再调ctx.write()，除非你明确要做代理转发；正常流程是处理参数、修改 msg、然后调super.write()或直接ctx.write()交给下一个 handler - 特别注意
exceptionCaught：它不自动传播，必须手动ctx.fireExceptionCaught(cause)，否则异常止步于此，上层无法兜底
最易被忽略的一点：handler 的线程安全性。Netty 不保证同一个 handler 的不同方法不会被不同 event loop 线程并发调用 —— 尤其当 handler 被多个 channel 共享（@Sharable）时。任何共享状态（如 AtomicInteger 计数器、ConcurrentMap）都得自己加锁或用线程安全类型，别想当然认为 “Netty 会串行”。
