gdb中无法真正“忽略”线程，需用thread apply显式限定操作范围或条件断点过滤：如thread apply 1 3 5 bt、break func thread 1、break func if $_thread==1。
gdb 中如何忽略特定线程（set scheduler-locking on 不能解决这个问题）
“忽略线程”不是指暂停它，而是让 info threads、thread apply all、断点命中等操作默认跳过——这靠 ignore 命令不行，gdb 没这个功能。真正有效的是用 thread apply 显式限定范围，或配合 set scheduler-locking + 线程过滤来控制调试焦点。
用 thread apply 限定只操作目标线程（最常用且可靠）
当你只关心主线程和 worker-2，其他 10 个日志线程、心跳线程全是干扰，就别用 thread apply all bt，改用显式列表：
-
thread apply 1 3 5 bt—— 只对线程 ID 为 1、3、5 的线程执行回溯 -
thread apply 1-3 7 bt—— 支持范围写法（注意中间是英文短横） - 查当前所有线程 ID 和状态：先运行
info threads，输出里第一列就是 ID，带*的是当前活跃线程 - 线程 ID 在 gdb 里是临时编号（不是 OS 的
tid），每次run后重排，所以不能硬编码；建议在断点触发后立刻记下关键线程 ID 再操作
用 set scheduler-locking 防止切到不关心的线程（避免单步时跳转）
set scheduler-locking on 的作用常被误解：它不会“隐藏”线程，但能确保你在某线程单步（step / next）时，其他线程完全不被调度——这对定位竞态或复现死锁很关键，尤其当你只想观察主线程调用链时：
-
set scheduler-locking on：当前线程独占 CPU，其余线程冻结（但仍在内存中，信号仍可送达） -
set scheduler-locking step：仅在单步/步入时锁定，继续（continue）时恢复调度（更安全，推荐） - ⚠️ 注意：若目标线程在
wait或pthread_cond_wait上阻塞，锁定后它仍卡住，此时需用thread <id></id>切到另一个线程手动唤醒，否则调试会僵住 - 该设置不影响
breakpoint hit：如果断点在被忽略的线程上命中，gdb 仍会停，得靠条件断点或ignore次数规避
用条件断点 + 线程 ID 过滤真正“屏蔽”不相关中断
想让某个断点只在主线程触发？直接加 thread 限定符：
break my_function thread 1
或者用运行时判断（适用于无法预知线程 ID 的场景）：
break my_function if $_thread == 1
$_thread 是 gdb 内置变量，值为当前线程的 gdb 内部 ID；你也可以用 $_pid 或 $_tid（后者对应 OS 的 tid，需 info threads 查看）：
-
break my_lock_guard::unlock if $_tid == 12345—— 锁释放只在指定 OS 线程中断 - 条件断点性能开销略高，频繁触发时可能拖慢运行，上线前记得
disable掉 - 注意：C++11
std::this_thread::get_id()返回的是std::thread::id，不能直接和$_tid比较；如需映射，可在代码里打印syscall(SYS_gettid)辅助对齐
线程调试真正的复杂点不在命令本身，而在于 gdb 的线程 ID 和 OS tid 的错位、条件断点的求值时机、以及 scheduler-locking 对阻塞系统调用的“假死”表现——这些细节不踩一遍坑很难记住。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
