构造器引用正确写法是MyClass::new而非new MyClass::new，编译器自动匹配参数；方法引用不支持自动装箱拆箱，类型必须严格一致；构造器引用不捕获变量，但所在lambda引用的局部变量需effectively final；泛型擦除和对象逃逸可能影响性能。
构造器引用写法不对，new 关键字不能出现
Java 8 中构造器引用不是写 new MyClass::new，而是直接用 MyClass::new。只要函数式接口的抽象方法参数能匹配构造器参数，编译器就能推导出你要调的是哪个构造器。
常见错误是手动补上 new，比如 Function<string string> f = new String::new</string> —— 这会报错，因为 new 是语句关键字，不能出现在引用位置。
-
Supplier<list>></list>→ArrayList::new（无参构造） -
Function<integer int></integer>→int[]::new（数组构造器是特例） -
BiFunction<string integer bigdecimal></string>→BigDecimal::new（匹配String, int构造器）
方法引用类型不匹配，编译器不会自动装箱/拆箱
方法引用对参数类型和返回类型要求严格，不会像 lambda 表达式那样隐式做基本类型与包装类转换。比如 ToIntFunction<integer></integer> 要求输入是 Integer、输出是 int，但你写 Integer::intValue 就行；换成 Function<integer int></integer> 就不行，因为后者返回类型是包装类 int（语法错误），实际是 Integer，而 intValue() 返回的是 int 基本类型，类型不兼容。
- 确认函数式接口定义的参数类型是否与目标方法签名完全一致
-
Long::parseLong可用于Function<string long></string>，但不能用于Function<string long></string>（后者非法） - 静态方法引用比实例方法引用更少受对象生命周期干扰，优先考虑
构造器引用捕获外部变量时，容易忽略 final 或 effectively final 限制
构造器引用本身不捕获变量，但如果你在 lambda 里用它，而 lambda 又引用了局部变量，那变量必须是 final 或 effectively final。这点常被误认为是构造器引用的问题，其实是闭包规则在起作用。
立即学习“Java免费学习笔记（深入）”；
比如：String prefix = "v1"; List<string> list = Arrays.asList("a", "b"); list.stream().map(s -> new Version(prefix + s)).collect(...)</string> —— 这里 prefix 必须是 effectively final，否则编译失败；换成 list.stream().map(s -> Version::new) 不成立，因为 Version(String) 构造器只接受一个参数，没法把 prefix 塞进去。
- 构造器引用无法携带额外上下文，需要拼接参数得靠 lambda 或预处理
- 想复用带前缀的构造逻辑，更适合封装成工厂方法，再引用该方法
- 泛型类的构造器引用可能触发类型擦除问题，比如
List<string>::new</string>实际擦除为List::new，运行时无法区分
方法引用性能看似好，但要注意对象创建开销和逃逸分析失效
方法引用本身没有额外开销，比等价 lambda 略轻（省去一次函数对象实例化），但很多人忽略：如果引用的是实例方法（如 str::toLowerCase），每次都会绑定当前对象，而这个对象若在流中反复使用，可能阻止 JIT 的逃逸分析，导致本可栈分配的对象被迫堆分配。
- 静态方法引用（
Objects::nonNull）和构造器引用最安全，无状态依赖 - 避免在高频循环中用
obj::method，尤其obj是临时或短生命周期对象时 - 用
javap -c看字节码可验证：方法引用通常编译为invokedynamic，但最终是否内联取决于运行时优化
