ctx.close() 是向pipeline后方发送close事件，触发后续handler响应；ctx.channel().close() 是直接关闭channel，跳过所有后续handler。
ctx.close() 是事件，ctx.channel().close() 是动作
这是最本质的区别：ctx.close() 向 pipeline **后方（tail 方向）发送一个 channelInactive + close 事件，让后续 handler 有机会响应；而 ctx.channel().close() 是直接调用 channel 底层关闭逻辑，**跳过当前 handler 之后的所有入站/出站处理器**，相当于“抄近路关闸”，不通知邻居。
常见错误现象：在 channelRead() 里收到一条“退出指令”后直接写 ctx.channel().close()，结果发现日志没记、编码器没 flush、响应包没发出去——因为那些 handler 根本没被触发。
- 使用场景：
ctx.close()用于业务逻辑中“我处理完了，现在要关连接”，需保障 pipeline 完整性；ctx.channel().close()仅适合底层兜底或极端紧急中断（如检测到非法协议头立即断连），且你明确知道后续无 handler 需参与 - 参数差异：两者都可传
ChannelPromise，但ctx.close(promise)会把 promise 传递给后续 close 处理器；ctx.channel().close(promise)则由 channel 自己管理 promise 状态，不经过 pipeline - 性能影响几乎可忽略，但语义和可靠性差异巨大——这不是性能问题，是协作契约问题
为什么 ctx.close() 只触发当前及之前 handler 的 close？
Netty pipeline 是双向链表，事件传播有方向性。ctx.close() 触发的是 outbound 事件，从当前 ChannelHandlerContext 开始，**向前（head 方向）逐个调用 close() 方法**，直到 head；而 ctx.channel().close() 是 channel 层发起的全链路 shutdown，会从 tail 开始触发所有 handler 的 close()，但绕过了 pipeline 的事件调度机制。
简单说：前者是“我喊一声，前面的人听见了再喊前面”，后者是“我直接按总闸，不管谁听见没听见”。
- 典型误用：
ctx.pipeline().last().close()看似“最后一个 handler 关”，实则仍是 outbound 传播，只影响它前面的 handler，和ctx.close()行为一致 - 验证方式：加几个带
System.out.println()的 handler，分别用两种方式关闭，观察哪几个的close()方法被调用 - 注意：
ctx.close()不会自动触发channelInactive()入站事件——那是连接真正断开时内核通知的；但它会触发 outbound 的close()和后续的disconnect()、close()链式调用
心跳超时或异常时该用哪个？
绝大多数情况用 ctx.close()，包括 IdleStateHandler 触发的超时、解码失败、认证失败等业务侧主动断连场景。
例如你在 userEventTriggered() 里判断心跳超时：
public void userEventTriggered(ChannelHandlerContext ctx, Object evt) {
if (evt instanceof IdleStateEvent) {
// ✅ 正确：走 pipeline，让日志、监控、清理 handler 有机会执行
ctx.close();
// ❌ 错误：跳过编码器，可能丢弃正在 flush 的心跳响应
// ctx.channel().close();
}
}
- 例外场景：TCP 半关闭后仍需读取对端残留数据，此时不能用
ctx.close()（它会关读写），而应调用ctx.channel().shutdownOutput()——但这和本文两个方法无关 - 如果用了
ctx.channel().close()还想补救，基本没戏：事件已跳过，buffer 没 flush、metrics 没上报、连接池没回收，只能靠外部监控兜底 - 特别提醒：
ctx.close()是异步的，返回的ChannelFuture表示“close 事件已发出”，不代表连接已关闭；真要等关闭完成，得监听 future 或用ctx.close().sync()（慎用，可能阻塞 IO 线程）
容易被忽略的“ctx”来源陷阱
很多人在非 handler 方法里（比如工具类、业务 service）拿到一个 ChannelHandlerContext，以为 ctx.close() 就一定安全——其实不然。如果这个 ctx 是从别的 handler 缓存来的、或跨线程传递的，它的 pipeline 关系可能已失效，甚至所属 channel 已关闭。
- 安全做法：只在当前 handler 的生命周期内（即
channelRead、userEventTriggered等回调中）使用ctx.close()；若需跨组件关闭，应通过Channel引用 + 状态检查，再调用channel.close() - 调试技巧：打印
ctx.pipeline().names()和ctx.channel().isActive()，确认上下文是否还有效 - 最隐蔽的坑：在
exceptionCaught()中调用ctx.channel().close()看似合理，但如果异常来自编码器，而你又跳过了它后面的 handler，就可能漏掉关键错误日志——这时反而该用ctx.close()，让异常沿 pipeline 继续传播并被日志 handler 捕获
