java nio的write()方法不保证一次性写完，因其返回实际写入字节数而非请求量，需循环调用直至buffer.hasremaining()为false；必须flip()后写、禁用clear()、非阻塞时配合op_write就绪事件。
Java NIO 中的 write() 方法（如 SocketChannel.write()、FileChannel.write()）**不保证一次性写完缓冲区中全部数据**，这是由底层 I/O 机制决定的——尤其是网络通道受发送缓冲区大小、阻塞/非阻塞模式、接收端处理能力等影响。因此，必须主动检查写入进度并循环调用，直到缓冲区无剩余数据。
为什么 write() 不能一次写完？
根本原因在于：该方法返回的是**实际写入的字节数**，而非请求写入的字节数。常见情况包括：
- SocketChannel 处于非阻塞模式时，内核发送缓冲区已满，只能写入部分数据，甚至返回 0
- 即使在阻塞模式下，FileChannel 的 write() 也可能因文件系统缓存策略或磁盘压力而分批落盘
- transferTo() 等零拷贝方法同样返回实际传输字节数，无法假设 count 全部完成
标准循环写入写法（核心逻辑）
关键不是“要不要循环”，而是**如何正确判断是否继续写**。必须依赖 buffer.hasRemaining()，而不是手动比较 position 和 limit —— 因为 write() 内部会自动更新 position。
- 每次 write() 后，buffer 的 position 会前移已写入的字节数，limit 保持不变
-
hasRemaining()等价于position ，语义清晰且不易出错 - 无需关心返回值是否为 0（非阻塞场景下可能短暂发生），只要 buffer 还有剩余，就继续调用
示例代码：
ByteBuffer buf = ByteBuffer.allocate(1024);
buf.put("Hello, NIO!".getBytes());
buf.flip(); // 切换至读模式，准备写出
while (buf.hasRemaining()) {
int written = channel.write(buf); // 可能写入 0、部分或全部
// 可选：记录日志或做超时判断，但不必在此处处理 written == 0 的特殊逻辑
}
配套注意事项（容易忽略的关键点）
循环本身只是手段，真正保障正确性的前提是上下文状态准确：
- 必须先 flip()，再写：未 flip 的 buffer 处于写模式，position 在末尾，limit 等于 capacity，此时 write() 会写 0 字节
- 不要在循环中反复 clear()：clear() 会重置 position=0、limit=capacity，导致重复写入旧数据或越界
- 非阻塞 SocketChannel 需配合 SelectionKey.OP_WRITE：仅当通道就绪可写时才执行上述循环，否则可能忙等或阻塞线程
- 大文件或高吞吐场景建议用 transferTo()：但同样要循环，依据其返回值累加已传输量，并更新 position
什么时候可以不用循环？
极少情况可省略，但需明确前提：
- 使用
FileOutputStream（非 FileChannel）写小数据，且确认是阻塞同步流 - 测试代码中数据极小（如几个字节）、环境稳定、不追求健壮性
- 但生产级网络通信、文件传输、零拷贝操作，一律按循环处理
省略循环看似简洁，实则埋下偶发丢数据隐患，调试成本远高于多写两行 while。
