usedelimiter() 无效的主因是不重置已缓冲输入流，仅影响后续token提取；需在首次next*调用前设置，避免混用nextline()，正则分隔符须正确转义，且注意空token和换行符残留问题。
Scanner.useDelimiter() 为什么设了没效果？
最常见的情况是：调用 useDelimiter() 之后，next() 或 nextInt() 依然按空格/换行切分——因为 useDelimiter() 只影响后续的 token 提取，**不重置已缓冲的输入流**。Scanner 在首次调用 next* 方法时才会真正开始按当前 delimiter 扫描；如果之前已触发过读取（比如构造后直接调用了 nextLine()），新 delimiter 就不会作用于已缓存的部分。
实操建议：
- 在创建
Scanner实例后、任何next*调用前，立即设置 delimiter - 避免混用
nextLine()和其他next*方法（它们对换行符的处理逻辑不同，易导致残留） - 若需多次切换分隔符，每次切换后用
skip("\s*")清掉可能残留的空白
用正则表达式定义多字符或复杂分隔符
useDelimiter() 接收的是正则表达式字符串，不是普通字符串。想用 "|"、"--" 或 "\s+\|\s+" 做分隔符，必须转义特殊字符。
常见错误现象：scanner.useDelimiter("|") 会把每个字符都当一个 token（因为 | 在正则中是“或”操作符）；scanner.useDelimiter(" ") 看似正常，但无法匹配多个连续空格或制表符。
实操建议：
- 字面量分隔符如
"|"→ 写成"\|" - 多个空白符（空格、tab、换行）→ 用
"\s+" - 自定义分隔符如
"::"→ 写成"::"（无特殊含义，无需转义） - 不确定是否要转义？先用
Pattern.quote("your-delimiter")包一层
和 nextLine() 混用时的换行符陷阱
当用 useDelimiter("|") 后调用 next() 读完一个字段，再调用 nextLine()，很可能读到空字符串——因为 next() 停在 | 处，而换行符仍留在输入缓冲区，nextLine() 直接把它当整行返回了。
使用场景：用户输入类似 "Alice|25|Engineer
"，想用 | 切字段，最后一段却意外为空。
实操建议：
- 统一用
next()系列配合自定义 delimiter，不要中途插nextLine() - 真需要读整行再解析，就别设 delimiter，改用
String.split() - 若必须混用，
next()后加一句scanner.skip("\R")跳过换行符（\R匹配所有 Unicode 换行序列）
性能与边界情况：空 token 和末尾分隔符
默认情况下，Scanner 会跳过匹配 delimiter 的开头和结尾部分，但不会自动过滤中间产生的空 token。例如输入 "a||b" 配合 useDelimiter("\|")，会得到三个 token："a"、""、"b"。这和 String.split() 的默认行为（丢弃末尾空串）不同。
参数差异：useDelimiter() 本身不提供“忽略空 token”开关；控制权完全在正则表达式里。
实操建议：
- 要跳过空 token，把 delimiter 改成
"\|+"（匹配一个或多个|），这样"a||b"就只分出"a"和"b" - 注意
hasNext()在遇到 EOF 且最后是 delimiter 时可能返回 false，即使你期望它吐出最后一个空 token - 生产环境建议优先用
BufferedReader+String.split()，更可控、无状态、无隐式缓冲干扰
真正麻烦的不是写对正则，而是 Scanner 内部状态和输入流位置的耦合——一旦混用方法或 delimiter 切换时机不对，后续所有读取都会偏移。留心缓冲区里还剩什么，比记住 API 更重要。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
