Lambda表达式对局部变量的捕获是编译器在创建对象时自动将其“当时”值复制为堆中隐式字段，基本类型复制数值、引用类型复制地址；强制effectively final确保副本与原始值一致，避免数据不一致。
lambda 表达式对局部变量的“物理复制”，不是程序员手动拷贝，而是 jvm（java）或编译器（c++）在生成 lambda 对象时，**自动把变量当时的值存进该对象的字段里**。这个动作发生在 lambda 创建那一刻，之后它就和原始变量彻底无关了。
为什么必须是“当时”的值？
局部变量存在栈上，方法一结束，栈帧就销毁，变量地址失效。但 Lambda 可能被传到别处、延迟执行，甚至跨线程运行。如果它还试图去“找”栈上的原变量，就会出错。
所以 JVM 不让它找，而是在构造 Lambda 对象时，把那个变量的值“快照”下来，作为对象内部的一个隐式字段保存在堆上。这相当于一次自动的、不可见的初始化：
- 基本类型（如 int x = 5）→ 复制数值 5 进去
- 引用类型（如 String s = "hello"）→ 复制的是引用值（即内存地址），不是字符串内容本身；只要 s 没被重新赋值，这个地址就固定了
effectively final 是为了保证复制安全
如果允许后续修改局部变量，比如：
int x = 10;
Runnable r = () -> System.out.println(x);
x = 20; // 此时 Lambda 已创建，内部存的仍是 10
外部逻辑以为“改了 x，Lambda 也会看到新值”，但实际不会——因为 Lambda 用的是创建时的副本。这种不一致容易引发 bug。强制 effectively final，等于告诉编译器和 JVM：“这个值定死了”，可以放心复制，不用管后续变化。
和成员变量/静态变量的区别
类的字段（this.field 或 static int y）本来就在堆上，生命周期与对象或类一致。Lambda 访问它们时不走捕获流程，而是直接通过 this 或类名访问，自然可以读写，也不需要 final。
换句话说：捕获只针对局部变量；复制只发生在局部变量身上；堆上的东西，本来就不需要复制。
C++ 中的对应行为更直观
C++ 的 [=] 就是显式声明“按值捕获所有用到的局部变量”，编译器会把这些变量作为匿名类的成员字段，在构造 Lambda 对象时一一赋值。而 [&] 则存的是指针或引用——这时候如果原变量已销毁（比如函数返回后还调用 Lambda），就是悬空引用，行为未定义。
Java 不提供引用捕获局部变量的选项，正是为了避免这类危险；它的“复制”设计，本质是一种保守但安全的默认策略。
