要让缓冲流支持回溯读取，需三步：一查markSupported()确认支持性；二设合理readlimit（非缓冲大小，而是最大试探距离）；三按规则调用mark/reset，注意reset会清空后续缓冲。替代方案有Pushback流、ByteBuffer position控制或自建缓存层。
要让缓冲流支持回溯读取，关键不是直接调用 mark() 和 reset()，而是先确认能力、再合理设限、最后按规则操作。BufferedInputStream 和 BufferedReader 的 mark/reset 不是“自动倒带”，而是一套需主动配合的缓冲契约。
第一步：必须先验证支持性，不能跳过
很多失败源于没检查 markSupported()。FileInputStream 本身不支持，BufferedInputStream 只是转发底层能力；如果包装的是 System.in 或某些 SocketInputStream，返回仍是 false。
- 每次调
mark()前，加一行判断：if (!in.markSupported()) throw new UnsupportedOperationException("mark not supported"); - 常见安全源头：FileInputStream（套 BufferedInputStream 后）、ByteArrayInputStream、StringReader、BufferedReader（包装了支持的 Reader）
- 常见不支持场景：InputStreamReader（除非底层 InputStream 显式支持并已缓冲）、未包装的 FileReader、网络流（多数实现不支持）
第二步：readlimit 不是缓冲大小，而是“最大试探距离”
mark(int readlimit) 的参数常被误读为“缓存多少字节”。它实际是告诉缓冲流：“我之后最多往前读这么多字节，你还得能让我 reset 回来”。是否真能成功，取决于两个条件：你读的字节数 ≤ readlimit，且这些字节仍在缓冲区内未被挤出。
- BufferedInputStream 默认缓冲区 8192 字节；若
readlimit ≤ 8192，通常够用；设为 10000 并不保证一定有效 - 设得太小（如只设 1），读 2 字节后
reset()就会失败；设得太大（如 1MB），可能提前扩容缓冲区，浪费内存 - 实操建议：按业务中最长可能的试探长度估算，加 20% 余量。例如解析标识符最多 64 字符，加空格和操作符，设
mark(128)
第三步：reset 后状态重置，但缓冲区可能已清空
reset() 表面是“回到标记点”，实际行为是：丢弃 mark 之后所有已读未消费的缓冲数据，并将下一次 read() 起始位置设回标记处。这带来几个易忽略细节：
- 如果 mark 后调过
skip(n)，而底层流不支持 skip（如某些网络流），skip()会真实读取并丢弃字节，导致标记位置“悬空”，reset()后读到的不是原数据 - 不要在
mark()和reset()之间跨方法传递流对象，或混用其他流操作（如available()、markSupported()多次调用） - reset 后缓冲区内容被清空，后续读取可能触发底层流重读——这不是 bug，是设计使然
更稳妥的替代方案（当 mark/reset 不可控时）
如果解析逻辑复杂、回溯距离难预估，或底层流不支持 mark，硬凑 mark/reset 反而增加风险。可考虑：
-
PushbackReader / PushbackInputStream：适合短距离回退（如退回一个运算符、一个分隔符），调
unread(int)把刚读的字节/字符“推回去”，无缓冲区大小限制 -
手动 position 控制（ByteBuffer 场景）：对字节缓冲，直接用
int pos = buffer.position();保存，需要时buffer.position(pos)恢复，简单可靠 -
预读缓存层：自己维护
char[]或byte[]缓存 +int offset，所有读取走该层，完全掌控回溯粒度和生命周期
