gdb中通过thread apply all bt查看各线程是否卡在pthread_mutex_lock、__lll_lock_wait或std::mutex::lock()等函数，再结合info threads与thread n逐个检查栈帧中lock_guard/scoped_lock构造状态，人工拼出“持有-等待”链以定位死锁。
gdb里怎么看哪些线程卡在lock()上
死锁发生时，程序没崩溃，只是不动了——这时候gdb里最直接的线索就是“谁在等锁”。运行thread apply all bt，所有线程的调用栈会打出来，重点扫一眼有没有线程停在pthread_mutex_lock、__lll_lock_wait或std::mutex::lock()这类函数里。如果两个线程分别卡在mtx_a.lock()和mtx_b.lock()，而它们各自已经持有了另一个锁（从栈帧往上翻能看见前一个lock_guard构造），基本就是经典AB/BA死锁。
为什么bt看不出谁拿了锁，得用info threads + thread N
thread apply all bt只告诉你“谁在等”，不告诉你“谁拿着”。要确认持有关系，得手动切到每个线程：info threads列出所有线程ID，再用thread N切换过去，逐个看它的栈顶是不是刚执行完lock_guard构造、还没走到析构位置。特别注意：如果某个线程的栈里有std::lock_guard对象但作用域还没退出，那它大概率还握着锁；而另一个线程正在等它释放——这个“持有-等待”链必须靠人工拼出来。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
std::scoped_lock让gdb回溯更干净，但别指望它自动报错
std::scoped_lock本身不带运行时检测，但它把多锁逻辑压进一个原子操作，所以gdb里看到的栈会更扁平：要么全拿到，要么全没拿到，不会出现“只拿了第一个锁、卡在第二个”的中间态。这反而降低了gdb里误判的风险。但注意，如果代码里混用了std::scoped_lock和裸mtx.lock()，或者某处漏了std::adopt_lock，gdb里依然会出现奇怪的锁状态——比如一个线程显示刚构造完scoped_lock，却在另一处又对同一个mtx调了lock()，这时gdb可能只报resource_deadlock_would_occur异常，而不是卡住。
别跳过-g编译和-pthread链接
没加-g，bt输出只有地址没有源码行号；没连-lpthread（或CMake里没设find_package(Threads REQUIRED)），gdb可能无法正确识别线程状态，甚至info threads返回空。常见坑是：用clang++编译时忘了-stdlib=libc++，导致std::mutex符号解析失败，bt里一堆问号。另外，Release模式下内联太多，栈帧被压平，建议调试阶段用-O1 -g折中。
