scanner.usedelimiter() 设了没效果，根本原因是它只影响后续next*调用的token切分，且必须在首次读取前设置；nextline()完全无视delimiter，混用会导致解析错乱。
Scanner.useDelimiter() 为什么设了没效果？
最常见的情况是：调用了 useDelimiter()，但后续用 next() 或 nextInt() 读取时行为没变。根本原因是——useDelimiter() 只影响「后续」的 token 切分，对已缓存或已触发的输入无效；更关键的是，它**不改变 System.in 的原始字节流行为**，只是告诉 Scanner “下次调用 next* 时，按这个规则切字符串”。
所以必须在创建 Scanner 实例后、第一次读取前就设置分隔符；如果已经调用过 nextLine() 或其他读取方法，再设 delimiter 就晚了。
- ✅ 正确顺序：
Scanner sc = new Scanner(System.in); sc.useDelimiter("，|;|\s+"); - ❌ 错误顺序：
Scanner sc = new Scanner(System.in); sc.nextLine(); sc.useDelimiter(",");（此时nextLine()已按默认换行符读完一整行，delimiter 失效） - ⚠️ 注意：正则表达式中的特殊字符（如
|、+、(）必须转义，"\s+"才表示“一个或多个空白字符”
怎么用正则写多分隔符（逗号、分号、中文顿号、空格混用）
实际输入常混用多种分隔符，比如用户输入 apple，banana; cherry date。这时不能只写 "，|;"，因为中文顿号和空格也要覆盖，且要处理连续空白。
推荐正则："[，;\s]+|\s+" 不够健壮；更稳妥的是 "[，;\s]+" （方括号内自动支持“任一字符”，+ 表示连续出现），但注意：方括号里 \s 会匹配所有 Unicode 空白（包括换行、制表符），而 \s+ 在方括号外是冗余的。
- ✅ 推荐写法：
sc.useDelimiter("[，;\s]+")—— 匹配中文顿号、英文分号、任意空白（含空格、制表、换行）的一个或多个连续组合 - ❌ 避免写
"，|;|\s+"——\s+是独立分支，会导致正则引擎尝试匹配“一个空白”或“多个空白”，逻辑冗余且易出边界问题 - ? 调试技巧：用
sc.findInLine(".*")或先sc.hasNext()观察是否真能切出 token，比盲目打印更可靠
next() 和 nextLine() 混用时 delimiter 为什么突然失效？
nextLine() 是个特例：它**完全无视 delimiter**，始终以换行符（
或
）为界读取整行。一旦你调用了 nextLine()，Scanner 的内部指针就跳到下一行开头，之前设的 delimiter 对它毫无作用。
更麻烦的是，如果先用 next()（受 delimiter 控制）读了几个 token，再调用 nextLine()，很可能读到一个空字符串——因为 next() 停在换行符前，nextLine() 立刻消费掉那个换行符并返回空。
- ✅ 统一风格：全用
next()系列（next()、nextInt()等），确保 delimiter 生效 - ✅ 或全用
nextLine()+ 手动split()：String[] parts = line.split("[，;\s]+")，更可控 - ⚠️ 混用雷区：
sc.nextInt(); sc.nextLine();后续再sc.next()—— 中间残留的换行符会让 delimiter 行为错乱
性能与边界：大输入、空 token、结尾分隔符怎么办
默认情况下，Scanner 会跳过分隔符之间的空 token（比如输入 a,,b 且 delimiter 是 ","，next() 只返回 a 和 b）。如果你需要保留空 token，得自己处理，因为 Scanner 没提供开关。
另外，大量输入时，Scanner 的正则匹配和缓冲机制比 BufferedReader + split() 慢不少，尤其 delimiter 正则复杂时。
- ✅ 处理空字段：改用
nextLine()读整行，再用String.split(regex, -1)（-1表示不丢弃结尾空串） - ✅ 性能敏感场景：直接用
BufferedReader+split()，避免Scanner的额外封装开销 - ⚠️ 特殊字符风险：如果 delimiter 正则里包含未转义的
$、^、.，会导致PatternSyntaxException，务必在 IDE 里测试正则或加 try-catch
