write()仅将数据写入Netty的ChannelOutboundBuffer缓冲队列，不触发系统调用；必须显式flush()或使用writeAndFlush()才能尝试刷入内核socket缓冲区，但成功与否取决于Socket状态、内核缓冲区空间及TCP_NODELAY设置。
Write只是把数据放进Netty自己的ChannelOutboundBuffer
调用 write() 不会立刻发到Socket，它只把ByteBuf塞进Netty内部的写缓冲队列（ChannelOutboundBuffer），等后续统一处理。这时候数据还在JVM堆或直接内存里，连内核缓冲区的边都没摸到。
常见错误现象：write() 后连接断了，但没报错，消息也丢了——因为根本没触发实际写出。
- 适用于攒批发送：比如你连续调用5次
write()，再统一flush()，能减少系统调用次数 - 必须配对使用
flush()，否则数据永远卡在Netty缓冲区 - 如果Channel是自动刷新模式（
config().setAutoFlush(true)），每次write()会隐式触发flush()，但不推荐依赖这个
WriteAndFlush = write() + flush()，但不是原子操作
writeAndFlush() 是两个动作的组合调用，不是底层单次系统调用。它先执行 write() 入队，再立即调用 flush() 尝试把整个缓冲区刷进内核socket缓冲区（即调用 writev() 或 send() 系统调用）。
关键点在于：“尝试”刷入——是否真进了内核缓冲区，取决于当前Socket状态和内核缓冲区余量。如果满载，数据可能卡在Netty缓冲区，等下次事件循环再重试。
- 适合对端等待响应的场景：比如RPC请求、HTTP短连接，需要尽快让对端收到
- 性能影响：频繁调用
writeAndFlush()会增加系统调用开销，尤其小包多时 - 注意异常时机：
writeAndFlush()返回的ChannelFuture失败，说明刷入内核失败（如连接已关闭、EAGAIN/EWOULDBLOCK），不是“发送成功”的保证
刷入内核缓冲区的实际触发条件
真正把数据交给操作系统，靠的是 flush() 触发的底层 writev() 调用，但能否成功还受三方面制约：
- Socket是否处于可写状态（由epoll/kqueue通知）——如果不可写，
flush()会静默排队，等下次OP_WRITE就绪 - 内核socket发送缓冲区是否有足够空间——空间不足时返回
EAGAIN，Netty会注册OP_WRITE继续等待 - 是否启用了TCP_NODELAY：若未禁用Nagle算法，小包可能被内核缓存合并，延迟进入网络（即使已刷入内核缓冲区）
验证方式：抓包看TCP PSH标志位，或用 ss -i 查看socket发送队列长度（tx_queue）。
容易被忽略的缓冲区层级和调试盲区
很多人以为“调用了 writeAndFlush() 就等于数据上 wire 了”，其实中间至少跨了四层缓冲：
- JVM堆/堆外内存（你的ByteBuf）
- Netty的
ChannelOutboundBuffer（可配置容量，默认无限） - 内核socket发送缓冲区（
net.core.wmem_default控制） - 网卡驱动环形缓冲区（更底层，通常不用管）
最常出问题的是第二层和第三层之间：比如你写了1MB数据，但内核缓冲区只剩64KB，那90%的数据会滞留在 ChannelOutboundBuffer 中，Channel.isActive() 仍为true，writeAndFlush() 的Future也可能成功完成（因为它只表示“已提交刷入请求”，不表示刷入成功）。这时候得监听 ChannelFuture.addListener() 并检查 isSuccess() 和异常类型，而不是只看是否完成。
