为何Collectors.summingInt()可直接接收方法引用而Collectors.joining()不行？——基于Cat类Stream收集场景的技术问询
这问题问得太到位了！我刚上手Java Stream的时候也被这个写法差异搞懵过，咱们一步步理清楚为啥会这样：
先看能正常运行的代码(1)
int tailsEndToEnd = cats.stream().collect(Collectors.summingInt(Cat::getTailLength));
Collectors.summingInt()的设计就是兼具元素转换与数值聚合的收集器，它的参数要求是一个ToIntFunction<T>函数式接口——简单说就是「输入一个T类型对象，返回一个int值」。而你的Cat::getTailLength完美匹配这个要求：输入Cat实例，返回int类型的尾巴长度，所以编译器能自动识别这个方法引用符合接口签名，直接传就没问题。
再看报错的代码(2)
String allNames = cats.stream().collect(Collectors.joining(Cat::getName));
问题核心在Collectors.joining()的重载逻辑上！翻JDK文档就能发现：joining的所有重载版本，只负责收集CharSequence类型的流（String是CharSequence的子类），它根本没有提供「接受映射函数把元素转成字符串」的版本。
换句话说，joining默认认为你流里的元素已经是字符串了，直接拿来拼接就行。但你现在流里是Cat对象，不是String，直接传Cat::getName的话，编译器找不到对应的重载方法——毕竟joining从来没说过它能帮你先把对象转成字符串再拼接。
为什么代码(3)就能正常工作？
cats.stream().collect(Collectors.mapping(Cat::getName, Collectors.joining(", ")));
Collectors.mapping()就是专门解决「先转换再收集」的问题的！它的作用是：先把流里的每个Cat对象通过Cat::getName转换成String类型，再把转换后的String流交给后面的joining收集器处理。这完全符合joining的要求——它拿到的是String流，自然能顺利完成拼接。
最后总结设计逻辑
这其实是Java Stream收集器的「职责分离」设计思路：
summingInt是一体化的聚合收集器，内置了「元素转int+求和」的完整逻辑；joining是专注字符串聚合的收集器，只负责处理已有的字符串元素，类型转换的活儿交给mapping这类工具收集器来做。
这种拆分让每个收集器的职责更单一，组合起来能实现更灵活的功能——比如你还可以用mapping把Cat转成其他类型，再交给别的收集器处理。
内容的提问来源于stack exchange，提问作者user3501758
