Stream.generate()生成验证码流需用无状态、线程安全的Supplier，推荐ThreadLocalRandom.current()和预缓存字符集，配合limit()终止无限流，去重应由业务层保障而非耦合在supplier中。
Stream.generate() 生成随机验证码流的核心逻辑
直接用 Stream.generate() 生成验证码流是可行的，但必须配合 Supplier<string></string> 实现——它不接受参数，每次调用只返回一个新字符串。关键不是“怎么造”，而是“怎么造得安全、可控、不重复过度”。
验证码字符串的生成函数必须是无状态且线程安全的
常见错误是把 Random 实例写成局部变量或反复 new，导致种子相同、序列重复；或者用 Math.random() 在高并发下出现弱随机性。
- 推荐用
ThreadLocalRandom.current()，避免锁竞争，且每个线程独立实例 - 字符集别硬写
"0123456789ABC..."，用char[]或String常量缓存，避免每次 generate 都新建对象 - 长度固定（如 6 位），不要在 supplier 里做条件判断或外部依赖（比如读配置），否则流失去纯函数特性
示例：
String chars = "ABCDEFGHJKLMNPQRSTUVWXYZ23456789"; // 去掉易混淆字符
Supplier<String> captchaSupplier = () -> {
StringBuilder sb = new StringBuilder(6);
for (int i = 0; i < 6; i++) {
int idx = ThreadLocalRandom.current().nextInt(chars.length());
sb.append(chars.charAt(idx));
}
return sb.toString();
};
无限流必须配合 limit() 或其他终止操作才能实际使用
Stream.generate(captchaSupplier) 确实是无限流，但直接 forEach 或不加限制地 collect 会 OOM 或卡死。没人真要“无限”，只是需要按需取。
- 测试时常用
.limit(10).toList()拿前 10 个 - Web 接口生成单个码：直接
captchaSupplier.get()更轻量，不必走 Stream - 批量预生成缓存（如 Redis）：用
generate(...).limit(1000).toArray(String[]::new) - 注意
generate是惰性的，没终端操作就不会执行 supplier，这点常被忽略
别把验证码流和去重逻辑耦合在一起
有人想“生成不重复的验证码流”，试图在 supplier 里查数据库或 Set 判重——这会让流变慢、不可预测、难以测试。
- 验证码唯一性应由业务层保障（比如入库时加唯一索引 + 重试）
- 流只负责“生成”，判重交给后续 pipeline（如
.distinct()），但注意distinct()会缓存所有已见元素，无限流+distinct = 内存爆炸 - 真正需要去重的场景，应先生成有限批次（如 100 个），再
distinct().limit(6)取够为止
复杂点在于：验证码安全性不取决于“是否无限”，而取决于字符集熵值、生成器种子质量、传输与存储环节。流只是个工厂流水线，别让它背安全的锅。
