peek() 仅用于调试观察，必须搭配终止操作才执行，位置决定输出内容，不可用于业务逻辑或副作用操作。
用 peek() 打印中间结果最直接有效，但必须配终止操作、注意位置、仅用于观察——它不改变数据，也不保证执行（尤其在短路或并行流中）。
peek() 必须搭配终止操作才生效
Stream 是惰性求值的，peek() 本身是中间操作，单独调用不会触发任何执行。
- ❌ 错误写法：
list.stream().peek(System.out::println).filter(x -> x > 0);→ 控制台静默，什么也不输出 - ✅ 正确写法：补上
.collect(Collectors.toList())、.forEach(...)或.count()等终止操作，整条流水线才会运行，peek才会执行 - 小技巧：调试时可临时加
.count()（轻量终止），避免改变原逻辑；正式代码中务必移除
把 peek 放在合适的位置才能看到想看的数据
peek() 观察的是“它所在位置流里当前的元素”，不是操作前或操作后——它的输出完全取决于前后中间操作的处理结果。
- 放在
filter前：看到全部原始元素 - 放在
filter后：只看到通过筛选的元素（数量变少） - 放在
map后：看到的是转换后的新值（如字符串已转大写、数字已乘2） - 示例：
.filter(s -> s.length() > 2).peek(s -> System.out.println("after filter: " + s))输出的一定是长度大于 2 的字符串
打印自定义对象时别依赖默认 toString()
如果流中是 User、Order 等对象，直接 peek(System.out::println) 往往只显示 User@xxxx，看不出实际字段。
- ✅ 推荐写法：
.peek(u -> System.out.printf("id=%d, name=%s, status=%s%n", u.getId(), u.getName(), u.getStatus())) - ⚠️ 注意判空：若字段可能为
null，需提前检查，否则peek内部抛NullPointerException会导致整个流中断 - ? 小提醒：重写
toString()也能解决，但显式格式化更可控、更易读
别把 peek 当业务逻辑用
peek() 的设计初衷就是调试观察，JVM 不承诺它一定执行（比如 findFirst() 可能只处理前几个元素），也不保证顺序（并行流中尤其明显）。
- ? 危险操作：在
peek里修改外部变量、更新数据库、发 HTTP 请求 - ? 隐患写法：
.peek(x -> list.add(x * 2))—— 这属于副作用，不可靠且违背函数式原则 - ✅ 安全边界：只做日志、打印、断点辅助（配合 IDE 插件如 Java Stream Debugger）
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
