Buffer.mark() 用于标记当前 position 快照供 reset() 回退，不保存数据或业务语义；能否映射“变量处理位置”取决于业务如何将字段解析逻辑与 position 移动绑定。
Buffer.mark() 的作用不是记录“变量处理位置”，而是标记当前读写指针（position）的一个快照，供后续 reset() 调用时快速回到该位置。它本质是缓冲区内部的一个临时锚点，不保存数据、不绑定变量、也不感知业务逻辑——能否用于“变量处理位置的回溯”，取决于你如何把业务语义映射到 position 的移动上。
mark() 与 reset() 的基本协作机制
Buffer 中的 mark 是一个可选标记位，默认未设置（调用 reset() 会抛 InvalidMarkException）。只有显式调用 mark() 后，它才被设为当前 position 值；之后无论 position 如何变化（如 get()/put()/flip()/compact() 等操作），只要未调用 clear() 或 re-allocate，mark 保持不变。reset() 则将 position 重置为 mark 所在位置。
- mark() 不改变 position，只“拍照”当前 position
- reset() 不恢复 limit 或 capacity，仅重设 position
- clear()、flip()、rewind() 会丢弃 mark（除非你手动重新 mark）
- mark 是 buffer 实例级别的状态，不可跨 buffer 共享
将业务“变量处理位置”映射到 position 的典型场景
所谓“变量处理位置”，实际是你在解析一段字节流（如协议报文、日志行、JSON 片段）时，某个关键字段（比如 header 长度、type 字段值、起始偏移）被读取后，需要暂存现场，以便后续校验失败时回退重试或跳过异常段。此时可把“刚读完该字段后的 position”作为 mark。
- 例如解析固定头 + 可变体协议：读完 4 字节 length 字段后立即 mark()，再按 length 读取 body；若 body 解析出错，调用 reset() 回到 length 后，可选择跳过整包或记录错误
- 又如解析多字段 CSV 行：每成功解析一个字段（用 slice() 或 relative get），就 mark() 下一字段起始位置；某字段格式非法时，reset() 回到上个 mark，转而尝试容错解析或报错定位
- 注意：mark 本身不携带上下文信息（如“这是第几个字段”），需由业务代码自行维护关联关系（比如用栈存 mark 对应的字段名）
安全使用 mark/reset 的关键注意事项
mark 不是万能回滚点，它的有效性高度依赖 buffer 的生命周期和操作序列。常见误用会导致 reset 失效或行为意外。
- 避免在 compact() 或 put() 导致 position > limit 后 reset —— 虽不报错，但可能使 position 超出有效范围，后续 get() 抛 BufferUnderflowException
- 不要依赖 mark 在多个线程间共享 —— Buffer 非线程安全，mark 是普通字段，无同步保障
- 若需多次嵌套回溯（如递归解析），不能只靠单个 mark；可结合 Stack
手动保存 position，或用 duplicate().slice() 切出子视图隔离处理 - 调试时可用 buffer.position() 和 buffer.limit() 打印辅助定位，mark 值无法直接获取（JDK 不提供 getMark()），只能通过 reset() 后读 position 间接验证
一个轻量级封装建议：MarkedBuffer 工具类
为降低出错概率，可简单封装一层，把 mark/reset 与业务意图显式绑定：
示例逻辑（伪代码）：
MarkedBuffer mb = new MarkedBuffer(byteBuffer);
mb.mark("header_length_read"); // 记录语义标签（仅用于 debug）
int len = mb.getInt();
mb.mark("body_start");
if (!mb.parseBody(len)) {
mb.reset("header_length_read"); // 按标签查找并 reset
mb.skip(4); // 跳过本包，继续下一条
}
这种封装不改变底层行为，但通过命名标记+异常友好提示，让“变量处理位置”的管理更可读、可维护。
