按引用捕获局部变量最核心风险是悬垂引用：Lambda在局部变量销毁后被调用，访问已析构对象导致未定义行为，常见表现包括崩溃、随机值或静默错误。
按引用捕获局部变量会引发悬垂引用
最核心的风险是：Lambda 表达式在局部作用域外被调用时，其捕获的局部变量早已销毁，此时访问 & 捕获的变量就是未定义行为——常见表现是程序崩溃、随机值或静默错误。
例如函数返回一个带 [&] 捕获的 Lambda：
auto make_bad_lambda() {
int x = 42;
return [&x]() { return x; }; // ❌ x 在函数返回后就析构了
}
// 调用结果不可预测
- 只要 Lambda 的生命周期 > 被捕获局部变量的生命周期，就危险
- 哪怕变量是
static或全局的，也得确认它不会在 Lambda 使用前被销毁（比如线程退出、模块卸载） - 编译器几乎不报错，运行时才暴露问题，调试成本高
[&] 不是捕获“所有变量”，只捕获实际使用的变量
很多人误以为 [&] 会把当前作用域里所有局部变量都拉进闭包，其实编译器只捕获 Lambda 函数体中真正读写过的变量。没用到的变量，哪怕声明了、初始化了，也不会出现在闭包里。
这既是优化，也是陷阱：你改了函数体逻辑，可能无意中引入新变量访问，导致原本安全的 Lambda 突然开始捕获不该捕获的东西。
立即学习“C++免费学习笔记（深入）”；
- 示例中
[&]捕获x和y，但不会捕获未使用的z -
[=]同理，只拷贝实际使用的变量，不是整个栈帧 - 想明确控制捕获范围，建议显式写出变量名，如
[&x, &y]，避免隐式依赖
引用捕获 + 多线程场景极易出错
多个线程同时通过引用修改同一个局部变量，既无同步又无所有权约束，结果完全不可控。尤其当 Lambda 被投递到线程池或异步任务中时，原始变量所在栈帧很可能已退出。
- 即使变量是
thread_local，也要确保每个线程的 Lambda 只访问自己线程的副本 - 若需跨线程共享状态，应改用
std::shared_ptr包裹堆对象，或用std::mutex保护访问 - 用
std::async或std::thread传参时，优先选值传递或移动语义，而非引用捕获
混合捕获时，& 和 = 的优先级与可变性要手动管理
混合捕获（如 [x, &y]）下，x 是只读副本，y 是可变引用——但这种差异不会在语法上高亮，容易在后续修改中误判语义。
- 如果 Lambda 内部对
y做了修改，而外部期望它不变，就会产生隐蔽副作用 - 捕获列表中变量顺序无关，但可读性差；建议把引用捕获集中放在前面，如
[&a, &b, c, d] - 想禁止修改任何被捕获变量，统一加
const限定符：[&a, b] () mutable { ... }允许改副本，但不能改引用；若需改引用，必须去掉mutable并确保外部变量本身非const
