Scanner.useDelimiter() 未生效主因是默认跳过空白且需在读取前设置；正则须显式处理空白、转义特殊字符（用Q...E）；CSV等复杂场景应弃用，改用split()或专用库。

Scanner.useDelimiter() 为什么设了没生效？

多数人设了 useDelimiter() 却发现 next() 还是按空格切——根本原因是：默认的 Scanner 构造器会跳过所有分隔符前后的空白（包括换行、制表符），而你设的正则如果没显式覆盖空白，它仍会把连续空白当一个分隔符吞掉，导致行为和预期不符。

• 必须在调用任何 nextXxx() 方法前设置 useDelimiter()，一旦开始读取，再改只影响后续调用
• 正则中若含 s 或 \s+，注意它和 Scanner 默认的 \p{javaWhitespace}+ 可能叠加，造成“多切一次”现象
• 想严格按指定符号切（比如只认逗号，无视空格），正则得写成 [,] 或 \Q,\E，避免隐式包含空白

用正则写分隔符时哪些字符要转义？

Java 字符串里反斜杠本身就要双写，正则引擎又吃一层，所以像 .（匹配点号）得写成 \.， 得写成 \t。更麻烦的是 $、^、[、] 这些在正则里有特殊含义的，不转义就会被当元字符处理。

• 匹配字面量 .、?、*、+、(、)、[、]、{、}、|、^、$，统一用 \Q...\E 包裹最安全，例如 \Q.\E
• 匹配换行符别用 ，Scanner 底层按 InputStream 读，不同平台换行符可能是 或 ，稳妥写法是 \R（Unicode 行终止符）
• 避免写 .* 当分隔符——它会贪婪匹配到末尾，导致只剩一个 token

解析 CSV 行时 useDelimiter() 的局限在哪？

useDelimiter() 天然不支持引号包裹字段（如 "a,b",c,"d,e,f"），它只会机械按正则切，遇到逗号就断，不管上下文。这不是 bug，是设计定位不同：Scanner 是简单流式分词器，不是 CSV 解析器。

Java 接口排错助手

在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。

下载

• 若数据不含引号、转义、换行，用 useDelimiter(",") + next() 能跑通，但字段首尾空格需手动 trim()
• 只要出现 "foo,bar" 这种，正则无法可靠识别——没有回溯能力，也没状态机支持嵌套结构
• 性能上，每次 next() 都重新编译正则（除非传入 Pattern 对象），高频解析时建议预编译：scanner.useDelimiter(Pattern.compile(","))

替代方案：什么时候该放弃 useDelimiter()？

当你需要处理带引号、转义、跨行字段，或要保留原始分隔符位置，或要批量解析整块文本而非逐 token 流式读——这时候 useDelimiter() 已经不是工具，而是障碍。

立即学习“Java免费学习笔记（深入）”；

• 纯字符串解析优先用 String.split()，它返回数组，可控性强，且支持 limit 参数控制分割次数
• CSV 场景直接上 OpenCSV 或 Apache Commons CSV，它们处理引号、换行、类型转换都经过实战检验
• 复杂格式（如日志、配置）用 Pattern + Matcher 手动匹配，比 Scanner 更灵活，错误定位也更明确

真正难的不是写对正则，而是判断当前问题是否属于 useDelimiter() 的能力边界——越早看清这点，越少在调试上浪费时间。