Lambda捕获列表写错会导致崩溃或未定义行为：[&]易致悬空引用，[=]对指针/不可复制对象仍危险；应显式捕获、慎用this、优先shared_ptr、注意std::thread只拷贝lambda。
lambda捕获列表写错会导致崩溃或未定义行为
直接在多线程中用[&]或[=]捕获局部变量，大概率出问题——线程启动后原函数栈帧可能已销毁，[&]捕获的引用就悬空；[=]看似安全，但若捕获了指针、智能指针或非可复制对象（比如std::mutex），照样编译失败或运行时异常。
- 优先显式捕获：只写真正需要的变量，如
[x, ptr]或[&ref, val] - 避免
[&]用于线程函数：除非你100%确定所有引用变量生命周期覆盖整个线程执行期 - 捕获
std::shared_ptr比裸指针更安全：例如[ptr = std::make_shared<int>(42)]</int>，确保资源存活 - 不要捕获
this隐式：写成[this]或更好是[self = shared_from_this()]（需类继承std::enable_shared_from_this）
std::thread构造时传lambda，捕获变量会被拷贝还是移动？
std::thread构造函数会对lambda对象做**拷贝**（C++11/14），即使你用std::move包装，底层仍要求lambda可拷贝。这意味着：捕获的变量必须满足可拷贝条件；若用了std::move捕获（如[val = std::move(x)]），那拷贝后的lambda里val是原值的副本，不是“转移”给线程的独占所有权。
- 想真正移动语义？改用
std::async或手动管理std::packaged_task，它们支持可移动lambda - 捕获大对象（如
std::vector）时，用[vec = std::move(vec)]能避免冗余拷贝，但注意：原函数里vec之后不能再用 - lambda本身不可拷贝？比如捕获了
std::unique_ptr——那就不能直接塞进std::thread，得包装成std::function或换用std::jthread（C++20）
在lambda里修改捕获变量，主线程能看见吗？
取决于捕获方式：[x]（值捕获）修改的是副本，主线程无感知；[&x]（引用捕获）修改的是原始变量，但多线程下不加同步就是数据竞争——undefined behavior，不是“可能看不到”，而是程序随时可能崩溃或产生随机结果。
- 需要共享修改？用
std::atomic类型（如std::atomic<int></int>）配合值捕获，安全且高效 - 必须用引用？加锁：捕获
std::mutex和被保护变量的引用，但注意std::mutex不可拷贝，只能[&mtx, &data]引用捕获 - 别依赖“先启动后修改”：线程调度不可控，
std::thread t([&x]{ x = 42; }); x = 0;的结果完全不确定
捕获this指针时，对象析构了线程还在跑怎么办？
这是最隐蔽的崩溃源：lambda捕获[this]后，线程继续访问成员变量或调用成员函数，但对象早已被析构。编译器不会报错，运行时表现为内存访问违规或静默错误。
立即学习“C++免费学习笔记（深入）”；
- 类必须继承
std::enable_shared_from_this<T>，并在启动线程前获取shared_ptr：例如auto self = shared_from_this(); std::thread([self]{ self->do_work(); }); - 如果无法改类设计，至少在析构函数里调用
join()或detach()并设标志位，在lambda开头检查if (!alive_.load()) return; - 别用
std::weak_ptr捕获后在lambda里lock()：虽然能避免悬挂，但lock()失败时逻辑要兜底，且增加分支开销
线程安全从来不是靠“捕获方式”单点解决的，而是生命周期管理、同步机制、所有权模型三者咬合的结果。漏掉任意一环，std::thread + lambda 就是定时炸弹。
