Netty为何将InboundHandler与OutboundHandler置于同一Pipeline中？

问题场景 #

作为Netty初学者，我对Pipeline的设计存疑：Netty把InboundHandler和OutboundHandler放在同一个Pipeline里，消息会自动跳过方向不匹配的处理器，流转逻辑是这样的：
A <--- InboundHandler --- OutboundHandler -----> B

我原本觉得，分成两个独立的Pipeline分别管入站和出站会更清晰，比如：

A --> InboundHandler  --> B
  <-- OutboundHandler <-- 

为什么Netty要这么设计？ #

• 共享状态更方便
  很多业务场景里，入站和出站处理需要共用同一套上下文信息——比如连接的会话ID、请求响应的关联标识、加密用的密钥等。要是拆成两个Pipeline，你得额外做状态同步，反而麻烦。同一个Pipeline里的Handler可以直接通过ChannelHandlerContext访问Channel的共享属性，或者在Handler实例里直接维护状态，不用跨管线折腾。

• 兼容双向Handler
  Netty里有不少同时处理入站和出站的Handler，比如SslHandler：既要解密入站数据，也要加密出站数据。如果拆成两个Pipeline，这类Handler要么得重复实例化，要么得在两个管线间传递状态，既浪费资源又容易出错。

• 简化生命周期管理
  每个Channel对应一个Pipeline，管线的生命周期和Channel绑定。要是拆成两个，你得维护两份Handler的添加、移除、初始化逻辑，出错概率直接翻倍。比如Channel断开时，要同时清理两个Pipeline的资源，平白增加维护成本。

• 双向交互更顺畅
  同一个Pipeline里，入站处理完可以直接触发出站操作——比如收到请求后立刻写响应，不用跨管线调度。这种设计让双向逻辑更连贯：比如在某个InboundHandler里处理完请求，直接调用ctx.writeAndFlush()就能触发后续OutboundHandler的处理，流程一气呵成。

• 降低认知负担
  乍一看两个管线更直观，但Netty的设计是让你只需要关注一个Pipeline的结构，通过Handler的接口类型区分处理方向。熟悉规则后，你不用纠结某个Handler该放哪个管线，只需要实现对应的ChannelInboundHandler或ChannelOutboundHandler接口就行，反而比维护两个管线更简单。

内容的提问来源于stack exchange，提问作者Master Qiao