Consumer接口核心约束是accept()必须执行且返回void，编译器强制禁止任何返回值；常见误用包括混淆Function/Predicate、在lambda中写return、错误赋值、andThen异常中断及滥用单参数接口处理多参场景。
Consumer 接口的核心约束：accept() 必须执行，且不能有 return
Consumeraccept(T) 方法签名强制 void 返回，编译器会直接拒绝任何试图返回值的写法。这不是风格建议，是接口契约。一旦你写成 str -> { return str.length(); }，IDE 会立刻报错：「incompatible types: int cannot be converted to void」。
常见错误现象包括：
- 误把
Function<string integer></string>当作Consumer<string></string>使用，结果在流操作中编译失败 - 在 lambda 体里写了
return（哪怕只是return;），触发编译错误 - 试图用
accept()的调用结果赋值给变量，比如String result = consumer.accept("x");—— 这根本通不过类型检查
andThen() 组合多个 Consumer 时，顺序和异常传播要手动兜底
andThen() 看似链式调用很顺滑，但它只是简单拼接：先执行当前 Consumer 的 accept()，再执行参数传入的另一个 Consumer 的 accept()。它不处理异常，也不做短路控制。
使用场景中容易踩的坑：
- 第一个
Consumer抛出RuntimeException，第二个根本不会执行，但调用方完全感知不到中断点在哪 -
andThen()返回的是新实例，原实例不变；反复链式调用会产生大量中间对象，高频循环中要注意 GC 压力 - 如果需要「无论前面是否失败，后面都必须执行」，得自己包一层 try-catch，例如：
c1.andThen(c2).andThen(c3)改为c1.andThen(x -> { try { c2.accept(x); } catch (Exception ignored) {} }).andThen(x -> { try { c3.accept(x); } catch (Exception ignored) {} })
Consumer 在 Stream 中的典型误用：filter/map/forEach 混淆
很多人想用 Consumer 实现过滤或转换逻辑，结果掉进语义陷阱。Stream 的 filter() 要求 Predicate<t></t>，map() 要求 Function<t></t>，只有 forEach() 明确接受 Consumer<t></t>。
正确用法示例：
list.stream()
.filter(s -> s != null && !s.trim().isEmpty()) // ← Predicate，不是 Consumer
.map(String::toUpperCase) // ← Function，不是 Consumer
.forEach(System.out::println); // ← 这里才轮到 Consumer
如果你硬把过滤逻辑塞进 Consumer，比如写成 forEach(s -> { if (s != null) process(s); })，就失去了惰性求值优势，也无法和其他中间操作组合。
Consumer 和 BiConsumer 的边界：单参数动作别强行塞双参
遇到两个输入参数（比如日志记录需同时传 level 和 message），别试图用 Consumer<object></object> 或 Consumer<map object>></map> 来凑合。Java 8 明确提供了 BiConsumer<t u></t>，它的 accept(T, U) 天然支持类型安全、可读性强、IDE 提示完整。
反模式示例：
- 用
Consumer<pair integer>></pair>替代BiConsumer<string integer></string>—— 多一层封装，无实际收益 - 把两个参数拼成 JSON 字符串再传给
Consumer<string></string>—— 序列化开销 + 运行时解析风险 - 在 lambda 里捕获外部变量模拟第二参数（如
final String prefix = "DEBUG"; list.forEach(s -> log(prefix, s))）—— 违反纯消费语义，且难以复用
真正复杂的状态协同动作，往往该考虑封装成普通方法或服务类，而不是靠 Consumer 堆砌副作用。
