IdleStateHandler的三个参数分别触发对应事件：readerIdleTime超时触发READER_IDLE（无数据读入），writerIdleTime超时触发WRITER_IDLE（无数据写出），allIdleTime超时触发ALL_IDLE（既无读也无写），且仅抛出IdleStateEvent，需在userEventTriggered中自行处理。
IdleStateHandler 的三个时间参数到底谁触发什么事件
很多人一上来就填 new IdleStateHandler(30, 30, 30)，结果心跳没发、连接也没断——根本原因是没搞清每个参数对应的真实行为。它不直接发包，只在满足条件时抛出 IdleStateEvent，后续动作全靠你自己在 userEventTriggered() 里写。
关键区别：
-
readerIdleTime：Channel 在指定时间内**没调用channelRead()**（即没收到数据），触发READER_IDLE -
writerIdleTime：Channel 在指定时间内**没调用write()或writeAndFlush()**（即没发出数据），触发WRITER_IDLE -
allIdleTime：Channel 在指定时间内**既没读也没写**，触发ALL_IDLE
注意：WRITER_IDLE 是最常用的心跳触发点，因为客户端保活的核心是「我得主动说我还活着」；而 READER_IDLE 更适合服务端判断「这客户端是不是挂了」，用来做超时踢人。
为什么加了 IdleStateHandler 却没看到心跳包发出
IdleStateHandler 本身不构造或发送任何字节，它只是个“闹钟”。常见错误是只加了处理器，但没实现事件响应逻辑。
典型漏掉的步骤：
- 没在
ChannelInboundHandler子类中重写userEventTriggered() - 写了但没做
if (evt instanceof IdleStateEvent)类型判断 - 判断了但没区分
state()，比如把WRITER_IDLE和READER_IDLE混着处理 - 写了发送逻辑，但没加
ctx.writeAndFlush(...)，只写了ctx.write(...)导致消息卡在 outbound buffer 里
示例（客户端发心跳）：
@Override
public void userEventTriggered(ChannelHandlerContext ctx, Object evt) throws Exception {
if (evt instanceof IdleStateEvent) {
IdleStateEvent e = (IdleStateEvent) evt;
if (e.state() == IdleState.WRITER_IDLE) {
// 此处必须构造并发送实际心跳内容，比如 PingMsg 或纯字符串
ctx.writeAndFlush("PING").addListener(ChannelFutureListener.CLOSE_ON_FAILURE);
}
}
super.userEventTriggered(ctx, evt);
}
客户端和服务端的心跳职责不能反着配
客户端和服务端对空闲状态的敏感点不同，配错会导致单向保活失效甚至误断。
推荐分工：
- 客户端配
new IdleStateHandler(0, 30, 0)：只监控写空闲，每 30 秒主动发一次PING，不关心自己有没有收数据 - 服务端配
new IdleStateHandler(45, 0, 0)：只监控读空闲，45 秒没收到任何数据（包括PING）就断连，避免僵尸连接堆积
为什么服务端不用 writerIdleTime？因为服务端通常不主动发起心跳（除非要做双向探测），它的核心任务是「及时发现失联客户端」。如果也配写空闲，反而可能因网络抖动导致服务端反复重发 PONG，加重负担。
Netty 层心跳和 TCP KeepAlive 别混用，也别指望后者能替代前者
ChannelOption.SO_KEEPALIVE 是操作系统级的底层保活，Linux 默认 2 小时才发第一个 probe，完全无法满足业务级实时性要求（比如 30 秒内检测断连）。
更麻烦的是：SO_KEEPALIVE 成功只说明「链路层可达」，不代表应用进程还活着。对方进程崩溃但 TCP 连接未 RST，KeepAlive 仍会认为连接正常。
所以真实项目里应该：
- 开启
SO_KEEPALIVE作为兜底（防物理断网后连接假死） - 必须用
IdleStateHandler做应用层心跳，且协议自定义（如PING/PONG字符串或结构化消息） - 服务端收到
PING后必须立即回PONG，否则客户端的READER_IDLE可能误触发
容易被忽略的一点：如果你用的是 SSL/TLS，记得把 IdleStateHandler 放在 SslHandler 之后，否则它看到的是加密字节流，无法准确判断业务层是否空闲。
