vscode调试多线程需手动配置：python须同时设"subprocess": true和"justmycode": false才能捕获子线程堆栈并命中lambda内断点；c++须-g -o0 -pthread编译、midebuggerpath指向原生gdb、setupcommands启用线程调试，且断点必须打在lambda体首行而非std::thread构造处。
VSCode 默认不自动显示所有线程，也不默认捕获子线程执行上下文——必须手动配置 launch.json、编译参数和调试器行为，否则你看到的永远只有主线程，其他线程卡在 pthread_cond_wait 或 std::this_thread::sleep_for 里却毫无察觉。
Python 多线程：subProcess 和 justMyCode 必须同时开
debugpy（VSCode Python 扩展默认后端）能跟踪子线程，但前提是它得“愿意进去看”。只设 "subProcess": true 不够，因为默认 "justMyCode": true 会把线程函数当成“第三方代码”跳过。
-
"subProcess": true：启用对 threading.Thread 启动的子线程的堆栈捕获（不是 multiprocessing！那是另一回事） -
"justMyCode": false：让调试器进入线程函数体内部，否则断点打在target=lambda: ...里根本不会命中 -
"console": "integratedTerminal"：避免 internalConsole 在多线程输出时卡死或丢日志 - 断点必须打在线程函数第一行可执行语句上，比如
print("thread start")，而不是threading.Thread(...)调用处
C++ 多线程：-g -O0 编译 + miDebuggerPath 指向真 GDB
线程列表为空？90% 是调试器压根没拿到 pthread 元数据。GDB 版本不对、编译选项激进、或 VSCode 配置漏项，都会导致 CALL STACK 面板只显示 Thread 1。
- 编译命令必须含
-g -O0 -pthread：-O2会让std::thread构造函数内联，调试器看不到独立线程帧；-pthread是链接 pthread 库的必要开关 -
miDebuggerPath必须是系统原生 GDB，例如/usr/bin/gdb，不能是gdb-multiarch或容器里精简版 -
setupCommands中加一条：{"description": "Enable thread debugging", "text": "-enable-pretty-printing"}，否则某些 GDB 版本会静默禁用线程视图 - macOS 用户若用 LLDB，
type必须设为"lldb"，且编译命令要用clang++ -std=c++17 -pthread
调试时怎么切线程、锁线程、看阻塞点
VSCode 不会自动聚焦卡住的线程——你得自己动手。光靠断点暂停整个进程，根本发现不了哪个线程在等锁、哪个在 sleep。
- 调试运行中，打开
CALL STACK面板，顶部下拉菜单手动切换线程（别只盯着 Thread 1） - 右键某线程 → “Switch to thread”，立刻查看它的调用栈和局部变量
- 在 DEBUG CONSOLE 输入
-exec info threads查所有线程状态；输入-exec thread 2切到 ID=2 的线程；输入-exec set scheduler-locking on锁定当前线程（其他线程暂停执行），方便单线程逻辑验证 - 若某线程停在
pthread_cond_wait或__lll_lock_wait，说明它在等条件变量或互斥锁——这时要检查共享变量值和其他线程是否已发 signal 或 unlock
容易被忽略的坑：lambda 断点失效、std::jthread 版本兼容、启动时机
你以为断点没生效，其实只是它根本没机会执行——或者执行了但符号没了。
- 断点打在
std::thread t{[](){ /* breakpoint here */ }};这行？无效。构造函数只创建对象，真正执行在t.join()前某个时刻，且可能被优化掉。断点必须打在 lambda 主体第一行 - C++20 的
std::jthread析构自动join()行为，VSCode 1.85+ 才能正确识别；旧版本会误判线程已退出，导致线程列表异常消失 - 想观察线程创建瞬间？
"stopOnEntry": false必须设，否则一启动就卡在main()，错过std::thread构造和调度 - Release 模式下调试基本无意义：
-O2会让简单 lambda 变成全局函数，符号名改变，断点绑定失败
最常被跳过的动作是：没确认 GDB 是否真的报告了多线程元数据，就直接看 CALL STACK；没手动切换线程，就断定“断点不触发”。线程调试不是“设了断点就停”，而是“先确认线程存在、再确认它跑到了哪、最后才决定在哪停”。
