scanner.reset() 无效因底层输入源不支持mark/reset（如system.in），仅stringreader等内存流可用；必须先mark()才可reset，否则抛ioexception；语义重置应重建scanner实例。
Scanner.reset 为什么调用后读不到新输入
因为 reset() 不重置底层输入源，只重置内部标记位置——前提是之前调用过 mark()。没 mark 就 reset，会直接抛 IOException: Resetting to invalid mark。
常见错误现象：scanner.reset() 后紧接着 scanner.nextLine() 返回空字符串或报错；或者看似“重置”了，但后续读的还是旧缓冲区里的残留内容。
- 必须先调用
scanner.mark(int readAheadLimit)（比如mark(1024)），才能用reset() -
readAheadLimit是关键：它限制从标记点起最多能读多少字符而不丢弃缓冲；超过后标记自动失效 - Java 的
Scanner默认不启用标记支持，mark()和reset()都依赖底层Readable是否支持（如StringReader支持，System.in不支持）
System.in 场景下 Scanner.reset 实际不可用
绝大多数交互式输入场景（比如读控制台）中，reset() 根本不起作用——因为 System.in 是个无缓冲、不支持回溯的流，Scanner 构造时包装的 InputStreamReader 也不支持 mark()。
使用场景：只有当你把 Scanner 绑定到 StringReader、BufferedReader（且其底层流支持 mark）或内存字节数组时，reset() 才可能生效。
立即学习“Java免费学习笔记（深入）”；
- 验证是否支持：调用
scanner.ioException()看是否为 null；更直接的是捕获IOException并检查消息是否含 “mark/reset not supported” - 替代方案：对
System.in，别指望reset()，改用重新构造Scanner，或缓存输入字符串再新建Scanner(new StringReader(cachedInput)) - 性能影响：即使支持，频繁
mark()/reset()会增加缓冲区拷贝开销，尤其在大文本解析中要谨慎
reset() 和 skip()、useDelimiter() 的配合陷阱
reset() 只影响读取位置，不影响分隔符、区域设置或跳过的模式。很多人误以为 reset 后分隔符也“回滚”，结果解析逻辑出错。
参数差异：分隔符是 Scanner 的状态属性，独立于输入流位置；reset() 不改变 useDelimiter() 设置，也不清除已跳过的空白或注释。
- 如果之前用
skip(Pattern)跳过一段，reset()后再next()仍按当前分隔符切分，不会“重试”跳过逻辑 - 修改分隔符后调用
reset()，新分隔符立即生效，但已读过的字符不会被重新切分 - 兼容性注意：Java 9+ 对某些流的 mark/reset 行为做了更严格的校验，老代码在升级后可能突然抛异常
真正需要“重置扫描器”的时候该怎么做
多数情况下，开发者想的“重置”其实是语义层面的：比如用户输错，想从头再读一遍；或解析失败后尝试换一种格式解析。这时硬用 reset() 是走错路。
可操作路径很明确：放弃 Scanner 自带的流式状态管理，改用可控的数据容器。
- 读完整行或整块输入到
String，再用多个Scanner实例分别解析（new Scanner(inputString)） - 对文件输入，用
RandomAccessFile或Files.readAllLines()加载后随机访问 - 若必须复用单个
Scanner，最稳的方式是关闭它、重建，并确保输入源本身可重复读（比如new ByteArrayInputStream(bytes)）
容易被忽略的一点：Scanner 的异常状态（比如 InputMismatchException）不会因 reset() 清除，下次调用仍可能沿用旧的失败上下文。真要“干净重启”，实例级重建比状态重置更可靠。
