作者回复: 你看的很细致，点赞，第四章雏形，所以直接写，方便起见，没有分，在第五章分了。看来把原理知识放前面还是有用的，直接能看出问题了。哈哈

作者回复: 1 业务handler的异常现在被分成两个部分了：读用异常处理，所以exceptionCaught才从ChannelHandler（Deprecated）搞到ChannelInboundHandler里面，而写是用 PromiseNotificationUtil.tryFailure(promise, cause, promise instanceof VoidChannelPromise ? null : logger);来控制，所以收集异常的exceptionCaught方法还是在用，只是说只针对读，所以才移动了位置； 其实这个分2部分，也可以参考第五章的25页的异常处理统计那部分，也能体现。 2 主要三个问题注意：（1）handler顺序 （2）handler是否可共享 （3）内部处理是否有有资源应该释放而未释放，比如堆外的bytebuf.

作者回复: 都是长连接，netty默认都是长连接，除非你显式特地去断，所以，你从两个角度分析:服务器端有没有断你的连接？客户端有没有断你的连接，都没有，肯定长连接，默认也是没有的，因为他也不知道你的逻辑是需要一个请求断一次还是一定时间才断。

作者回复: 你理解的没问题，直接channel read里写也没问题，因为已经是一次完整请求了，写在complete里面有好处，就是减少flush次数，这个在第五章会详细说，这里是案例雏形，所以先用最简单的方式展示给大家，另外你说的部分数据，到了业务层已经包含完整请求了，在一次解码的handler里倒是可能是“部分”，所以这里功能没有问题的。

作者回复: 这里的close指的是服务器/客户端的关闭，不是单个连接的关闭。