markLimit是回溯许可距离而非缓冲区大小，其作用是提示reset时允许的最大回溯字节数，但reset能否成功取决于缓冲区实际容量是否足以保留mark位置到当前读取位置的数据。
markLimit 不是缓冲区大小，而是“回溯许可距离”
很多人误以为 mark(int readlimit) 的参数 readlimit 是 Buffer 内部要分配的缓冲字节数。其实不然——它只是一个**语义提示**：告诉 BufferedInputStream：“我之后最多可能从 mark 位置往后再读多少字节，还希望 reset 能成功”。这个值不会直接决定 buf 数组长度，但会影响内部是否扩容、以及 reset 是否被允许。
真正起决定性作用的是：BufferedInputStream 实际的缓冲区大小（buf.length）。源码中，markpos 记录标记时的 pos，而 reset() 成功的前提是：当前读取位置 pos ≤ markpos + readlimit，且更关键的是——markpos 到当前 pos 之间的所有数据，必须仍完整保留在 buf 数组中。
缓冲区大小比 readlimit 更直接影响 reset 结果
BufferedInputStream 默认缓冲区为 8192 字节。如果构造时指定缓冲区为 4096，那么即使你调用 mark(10000)，只要后续读取超过 4096 字节，缓冲区就会被填满并触发 refill（即丢弃旧数据、从底层流重新读），此时 markpos 指向的位置已不在缓冲区内，reset() 必然失败。
反过来说，哪怕你 mark(100)，但缓冲区是 8192，只要你没读满 8192 字节，reset 就大概率能成功——因为数据还在内存里，根本没被冲掉。
- 缓冲区大小 ≥ 实际已读字节数（从 mark 开始算）→ reset 可能成功
- 缓冲区大小 ＜ 实际已读字节数 → markpos 对应数据已丢失 → reset 抛 IOException: Resetting to invalid mark
- readlimit 设得再大，若缓冲区太小，也无济于事；反之，readlimit 偏小但缓冲区足够，reset 仍可工作
如何设置才能让 reset 稳定生效
要保障 reset 可靠，不能只看 readlimit，必须协同控制两个变量：
- 按需估算最大回溯距离：比如解析协议头时需反复查看前 2KB 数据，则 readlimit 至少设为 2048
- 显式指定缓冲区大小 ≥ readlimit：构造时传入 new BufferedInputStream(in, Math.max(8192, readlimit))
- 始终检查 markSupported()：避免包装了不支持 mark 的底层流（如 System.in 或某些 SocketInputStream）
- 避免在 mark 后调用 skip()：skip 可能真实消费字节而不进缓冲区，导致 markpos “悬空”
一个典型失败场景还原
假设用默认缓冲区（8192）的 BufferedInputStream 包装 FileInputStream，执行：
- 读了 5000 字节 → 调 mark(1024)（仅提示 1KB 回溯）
- 继续读 4000 字节（累计 9000）→ 缓冲区已 refill 过至少一次，原始 markpos 数据被覆盖
- 此时调 reset() → 抛异常，尽管只超了 readlimit 1024，但实际已远超缓冲区容量
真正卡住 reset 的，从来不是 readlimit 的数字，而是那块有限的 buf 数组有没有把 mark 那一刻的数据留住。
