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 - 匹配换行符别用
InputStream读，不同平台换行符可能是\R（Unicode 行终止符） - 避免写
.*当分隔符——它会贪婪匹配到末尾，导致只剩一个 token
解析 CSV 行时 useDelimiter() 的局限在哪？
useDelimiter() 天然不支持引号包裹字段（如 "a,b",c,"d,e,f"），它只会机械按正则切，遇到逗号就断，不管上下文。这不是 bug，是设计定位不同：Scanner 是简单流式分词器，不是 CSV 解析器。
- 若数据不含引号、转义、换行，用
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() 的能力边界——越早看清这点，越少在调试上浪费时间。
