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