mark() 需先调用 markSupported() 判断支持性，否则 reset() 必抛异常；readlimit 是最大回溯字节数而非缓冲区大小；reset() 后缓冲区清空且可能触发重读；多线程不安全，大数据回溯应改用 ByteArrayInputStream 等替代方案。
mark() 不是万能的，必须配合 markSupported() 判断
很多同学一上来就调 mark(1024)，然后直接 reset()，结果抛 IOException: mark/reset not supported。这是因为底层输入流（比如 FileInputStream）本身不支持 mark，而 BufferedInputStream 只是“转发”了这个能力——它只在包装的支持 mark 的流上才真正生效。更常见的是，即使你用了 BufferedInputStream，如果构造时传入的是不支持 mark 的流（如 System.in 在多数 JVM 实现中），markSupported() 仍返回 false。
实操建议：
- 每次调
mark()前，先用in.markSupported()检查，否则 reset 必然失败 - 不要假设
BufferedInputStream自带 mark 能力；它的作用是「提供缓冲 + 有条件地支持 mark/reset」 - 常见支持 mark 的源头：文件流（
FileInputStream）、字节数组流（ByteArrayInputStream）、某些网络流（需具体看实现）
readlimit 参数不是缓冲区大小，而是“可回溯的最大字节数”
mark(int readlimit) 的参数常被误解为“最多缓存多少字节”。实际上，它只是向 BufferedInputStream 提示：“我之后最多可能往前 reset 多少字节”。BufferedInputStream 会据此决定是否扩容内部缓冲区，但不保证一定缓存满 readlimit 字节——如果已读数据超过该值，再调 reset() 就会失败（抛 IOException: Resetting to invalid mark）。
实操建议：
- 设
readlimit时，按你实际需要回溯的**最大距离**来估算，留 20% 余量（比如要回溯最多 8KB，设mark(10240)） - 如果
readlimit设得太小，后续读取超出后reset()无效；设得太大又浪费内存（缓冲区可能提前扩容） - 内部缓冲区默认大小是 8192 字节，若
readlimit ≤ 缓冲区大小，通常能安全回溯；超过则依赖具体读取节奏
reset() 后，流位置回到 mark 处，但缓冲区状态可能不一致
reset() 表面是“倒带”，但底层行为是：丢弃 mark 之后所有已读未消费的缓冲数据，并把下一次 read() 的起始点设回 mark 位置。问题在于，如果 mark 后你调过 skip()、或用 read(byte[]) 读了一大块，缓冲区指针和底层流位置可能不同步——尤其当底层流不支持 skip()（如某些 socket 流），skip() 会真实读取并丢弃字节，导致 mark 位置“悬空”。
实操建议：
- 避免在
mark()和reset()之间混用skip()；如必须跳过，优先用read()配合丢弃字节 -
reset()后首次read()可能触发底层流重新读取（因为缓冲区已清空），性能比连续读略差 - 不要在多线程中对同一
BufferedInputStream并发调mark()/reset()，无同步保障
替代方案：何时该放弃 mark/reset，改用其他方式
mark/reset 本质是“轻量级回溯”，适合小范围试探（比如解析协议头、跳过 BOM、预读几个字节判断类型）。一旦需要回溯几百 KB 以上，或逻辑复杂（多次嵌套 mark），就容易出错且难调试。
实操建议：
- 读取前先用
ByteArrayInputStream把整段数据载入内存（适用于可控大小的数据） - 用
PushbackInputStream替代——它专为“推回少量字节”设计，接口更直白，不依赖 mark 机制 - 协议解析类场景，直接用
ByteBuffer或InputStream.readAllBytes()（Java 11+）转成 byte[] 再随机访问 - 如果底层是
FileInputStream，直接调getChannel().position(newPos)更可靠
真正麻烦的不是语法，而是 mark 语义的模糊性：它既依赖底层流支持，又受缓冲策略影响，还隐含时间窗口（两次 mark 会覆盖前一个）。用之前，先确认你的数据规模、回溯距离、以及底层流是否真靠谱。
