断点必须打在lambda调用处而非定义行，因定义只构造闭包对象；调试时需用print查看捕获变量，info locals无法显示；引用捕获常显示为空，可改值捕获或加命名引用绕过；qt信号槽中lambda类型被抹除，应提取为具名变量。
断点打在lambda定义行没用，得打在调用处
GDB 无法直接在 auto f = [](int x) { return x * 2; }; 这一行设有效断点——因为这行只构造闭包对象，不执行函数体。真正生成可调试的机器指令的是 operator() 调用点。
常见错误现象：在 lambda 定义行按 F9（或 break 命令）后，info breakpoints 显示 pending，运行时完全不中断。
- 正确做法：在
f(42)或std::sort(..., [](auto& a, auto& b) { ... });这类调用位置设断点 - 如果调用是隐式的（如 STL 算法内部），可用
break std::sort后单步进入，或直接break <code>__lambda_.*::operator()（需先用info functions lambda或rbreak lambda探测符号） - GCC 编译时必须带
-g，且避免-O2及以上优化；-O0是调试 lambda 的底线
查看lambda捕获变量要用print，不是info locals
info locals 只显示当前栈帧的局部变量，而 lambda 捕获的变量是其闭包对象的成员，不在当前作用域的局部变量表里。
例如：int x = 10; auto l = [x](int y) { return x + y; };，在 l(5) 断点处：
-
print x会报错 “No symbol 'x' in current context” - 必须先用
print l查看闭包对象地址，再print *(decltype(l)*)&l展开结构体成员 - 更直接的方式：
print ((const decltype(l)*)&l)->x（注意 const 修饰符，因默认operator()是 const 成员） - 若用了
mutable，则去掉const：print ((decltype(l)*)&l)->x
引用捕获的变量在GDB里可能显示为“”
即使加了 -O0 -g，GDB 仍常把引用捕获的变量（如 [&x]）显示为 <optimized out></optimized>——这不是优化导致，而是 GCC 在 GIMPLE 阶段将引用降级为指针，调试信息未完整保留绑定关系。
解决办法有限，但可绕过：
- 改用值捕获
[x]，此时print能直接看到副本值 - 在 lambda 外部临时加一句
int& ref_x = x;，然后在 lambda 内用[ref_x]，GDB 对命名引用支持更好 - 用
disassemble查看operator()的汇编，从mov/lea指令反推引用所指向的地址，再x/dw查内存
Qt信号槽连lambda时，GDB看不到闭包类型名
Qt 的 connect(obj, &Obj::sig, [=](int v){ ... }); 中，lambda 被包装进 QMetaObject::activate 调用链，GDB 默认不显示其真实闭包类型——因为 Qt 元对象系统抹去了原始类型信息，只留下 std::function 或 void* 回调。
这意味着你无法用 print l.x 查看捕获值，也无法在调用栈里直接定位到 lambda 函数体。
- 临时方案：把 lambda 提取为具名变量，再传给
connect，这样 GDB 能识别其类型 - 更可靠的做法：在 lambda 体内第一行加
qDebug() ，配合 <code>set follow-fork-mode child和日志断点定位 - 终极手段：用
gcc -fdump-tree-gimple生成中间表示文件，人工查闭包类字段名和初始化逻辑
GDB 调试 lambda 最难的不是设断点，而是接受它本质是个匿名类对象——所有操作都要按“对象+成员+成员函数”的思路来，不能当成普通函数去查变量、看调用栈。一旦习惯用 print 直接访问闭包成员，而不是依赖 IDE 自动展开，大部分卡点就自然解开了。
