捕获 this 后调用成员函数会崩溃，因为 this 是裸指针，lambda 仅复制指针值而不延长对象生命周期；若 lambda 在对象析构后执行，this 成悬空指针，导致未定义行为（如段错误）。
为什么捕获 this 后调用成员函数会崩溃？
因为 this 是裸指针，lambda 捕获它只是复制了指针值，并不延长对象生命周期。如果 lambda 在对象析构后执行，this 就变成悬空指针，访问成员变量或调用成员函数就会未定义行为（常见表现：段错误、随机 crash、读到垃圾值）。
典型出问题场景：std::thread、std::async、异步回调（如 Qt 的 QTimer::singleShot）、事件队列中保存 lambda 并延迟执行。
- 用
[this]捕获时，确保 lambda 执行前对象还活着 —— 这通常很难保证，尤其在多线程或异步上下文中 - 避免在 lambda 体内直接调用非
const成员函数，除非你 100% 控制生命周期 - 调试时可加断言：
assert(this != nullptr);，但这只是掩耳盗铃，不解决根本问题
[=] 和 [&] 捕获对 this 的行为一样吗？
是的 —— 在 C++11 及以后，[=] 和 [&] 都会隐式按值捕获 this 指针（即复制指针，不是对象本身）。这不是“捕获所有成员”，而是语言规则：类内 lambda 的默认捕获若含 this，一律按值捕获指针。
所以：[=] { foo(); } 和 [this] { foo(); } 行为完全一致；[&] { foo(); } 也等价，**不是**按引用捕获整个对象。
立即学习“C++免费学习笔记（深入）”；
-
[=]还会按值捕获所有自动变量，可能引发意外拷贝或悬挂（比如捕获了局部std::string，但 lambda 延迟执行时它已析构） -
[&]对自动变量是引用捕获，更危险：一旦 lambda 执行时那些变量已出作用域，就直接 UB - 显式写
[this]比[=]更清晰，表明你只依赖当前对象状态，不依赖外围局部变量
如何安全地在 lambda 中访问类成员？
核心思路：把对象生命周期和 lambda 绑定起来。最常用且推荐的方式是捕获 shared_ptr<self_type>。
前提是你这个类支持被 shared_ptr 管理（通常继承自 std::enable_shared_from_this<T>）：
class Widget : public std::enable_shared_from_this<Widget> {
public:
void startAsync() {
auto self = shared_from_this(); // 安全获取 shared_ptr
std::async(std::launch::async, [self]() {
self->doWork(); // self 保证对象存活
});
}
private:
void doWork() { /* ... */ }
};- 必须在对象已被
shared_ptr管理后调用shared_from_this()，否则抛std::bad_weak_ptr - 不要在构造函数里调用
shared_from_this()—— 此时shared_ptr还没接管对象 - 如果无法改用
shared_ptr（比如 legacy 类），只能靠外部保证生命周期，例如用std::weak_ptr+lock()检查再执行
捕获 this 时能访问 private 成员吗？
可以。lambda 是定义在类作用域内的，它拥有和所在成员函数相同的访问权限 —— 不受 private / protected 限制。这不是“绕过”封装，而是语言设计使然。
但要注意：如果 lambda 被传到类外（比如作为回调注册给第三方库），而该 lambda 又访问了 private 成员，那等于把内部实现细节暴露出去，破坏了封装意图。
- 编译器不会报错，但逻辑上可能违背设计契约
- 若需暴露能力，应提供
public或protected接口，让 lambda 调用接口而非直接碰成员 - 尤其注意
mutablelambda 修改const成员变量 —— 即使语法允许，也可能违反类不变量
C++ lambda 捕获 this 看似简单，真正麻烦的是对象生命周期管理。很多人只关注“能不能编译”，却忽略“什么时候执行”。最易被忽略的点是：即使你用了 shared_from_this()，如果对象本身是栈对象（没被 shared_ptr 持有），调用它就会立即崩溃 —— 这种错误往往只在特定路径下触发，极难复现。
