IO异常时须在抛出前一刻捕获缓冲区状态，因catch中局部变量可能被JIT优化、缓冲区已被复用或释放，且buf.position()等调用本身可能引发新异常；应于read/write后立即记录position/limit/remaining原始值，优先通过自定义IoSnapshotException携带上下文，避免依赖反射或MDC透传。
IO 异常发生时，缓冲区 position、limit、capacity 等状态值往往比堆栈更关键——它们能直接说明“读到哪了”“写偏移多少”“是否因越界触发异常”。但这些变量极易在异常传播过程中丢失或被优化掉，必须在 抛出异常前一刻 主动捕获并固化。
为什么不能等 catch 块里再取？
一旦 IOException 抛出，执行流已离开 IO 操作现场。此时：
- 局部缓冲区变量（如 ByteBuffer buf）可能已被 JIT 优化为寄存器值，无法通过反射访问；
- 若缓冲区是方法参数传入，调用方可能已复用或重置它（比如 Netty 的 PooledByteBuf）；
- 调用 buf.position() 等方法本身可能触发额外异常（如 buffer 已释放），导致日志逻辑崩溃。
安全提取缓冲区快照的实操要点
核心原则：在调用 read()/write()/get() 等 IO 方法 之后、检查返回值之前，立即记录缓冲区状态。
- 对 NIO 通道操作，推荐在每次 IO 调用后封装一层状态快照逻辑：position = buf.position(); limit = buf.limit(); remaining = buf.remaining();
- 只记录原始数值，不调用 toString() 或 format 方法——避免隐式对象创建和潜在异常；
- 若使用 MDC，转成字符串后立即塞入：MDC.put("buf_pos", String.valueOf(position));，并在 IO 完成后及时清理；
- 对 FileChannel 或 SocketChannel 的 write()，特别关注返回值：若返回 -1 或小于预期字节数，应立刻捕获当前 buffer 状态，而非等到异常抛出才行动。
结合异常构造体传递上下文
自定义 IO 异常类是最稳妥的载体：
- 定义 class IoSnapshotException extends IOException，构造函数接收 position、limit、remaining、channelName 等字段；
- 在 IO 失败分支中直接 new 异常：throw new IoSnapshotException("Write failed", position, limit, channel.id());；
- 这样所有关键变量随异常对象一起进入堆栈，不受后续 GC 或线程切换影响，且日志解析可结构化提取。
避免踩坑的边界情况
某些场景下缓冲区状态需额外判断：
- DirectBuffer 可能因 native 内存释放而失效，快照中应补充 buf.isDirect() 和 buf.isReadOnly() 标志；
- 异步 IO（如 AsynchronousSocketChannel）中，回调函数运行在线程池，MDC 不自动继承，需显式 MDC.getCopy() 透传；
- 使用零拷贝 sendfile 时，position 实际由内核维护，Java 层 buffer 的 position 可能未更新——此时应以系统调用返回的 offset 为准，而非 buffer.position()。
