StringTokenizer 不比 split 更高效，且是已废弃的遗留类；它不支持正则、空分隔符和空字段保留，性能更差；推荐用 split（可配负参数保留空项）或预编译 Pattern。
StringTokenizer 不比 split 更高效，而且在绝大多数场景下不推荐使用。
StringTokenizer 已被官方标记为“遗留类”
Java 从 1.0 就带了 StringTokenizer，但它早在 Java 1.4 的文档里就被明确标注为 “legacy class”，意思是“为了向后兼容才保留，新代码不应使用”。它没实现 Iterator，不支持正则，也不能处理空字段（比如连续分隔符），更关键的是——它压根没做性能优化。
-
split()底层用Pattern编译正则，首次调用稍慢，但后续复用Pattern.compile()可完全规避开销 -
StringTokenizer每次都手动扫描字符串，无缓存、无预编译，纯靠 while 循环 +indexOf，对长字符串反而更慢 - JDK 9+ 中，
String.split()还做了内联优化和分支预测提示，实际基准测试中普遍快 10%~30%
split("") 和 StringTokenizer 处理空字符串的行为完全不同
这是最容易踩坑的地方：想把字符串拆成单字符数组？很多人直觉写 new StringTokenizer(str, "")，结果抛 IllegalArgumentException —— StringTokenizer 的分隔符不能为空字符串。
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
-
str.split("")能正常返回每个字符（首尾会多出空串，需过滤） - 想安全切单字符，应该用
str.chars().mapToObj(c -> String.valueOf((char) c)).toArray(String[]::new)或直接str.toCharArray() - 如果硬要用
StringTokenizer，必须指定非空分隔符，比如逗号或制表符，否则运行时报错
替代方案：简单场景用 split，高频/复杂场景预编译 Pattern
除非你在维护 2002 年的遗留系统，否则别碰 StringTokenizer。现代写法更清晰、更可控、也更快。
立即学习“Java免费学习笔记（深入）”；
- 普通分隔：直接
"a,b,c".split(",")，注意它会把"a,,c"拆成长度为 3 的数组（跳过空字段），而StringTokenizer会返回 2 个 token - 要保留空字段？加负数参数：
"a,,c".split(",", -1)→ 长度为 3 的数组，含中间空串 - 高频调用（如日志解析）？提前编译：
private static final Pattern COMMA_SPLIT = Pattern.compile(",");，然后用COMMA_SPLIT.split(str) - 需要忽略空白或多种分隔符？
split("\s+|[,;\t]")一行搞定，StringTokenizer做不到
真正影响性能的从来不是选 StringTokenizer 还是 split，而是反复创建正则对象、没考虑空字段语义、或者在循环里对同一字符串反复分词。这些细节比类名选择重要得多。
