vscode多线程调试需手动切换线程查看阻塞状态，确保-g -o0编译、正确配置midebuggerpath和setupcommands启用线程调试，断点打在lambda内部而非std::thread构造处，并启用subprocess支持python子线程。
VSCode 调试时线程全卡在 pthread_cond_wait 或 std::this_thread::sleep_for
这是最典型的「看似断点没生效，其实线程根本没跑起来」现象。VSCode 默认只显示当前活动线程的调用栈，其他线程可能处于阻塞/等待状态，但调试器不会主动聚焦它们——你得手动切过去看。
- 按
Ctrl+Shift+D打开调试面板后，左上角线程下拉菜单必须手动切换，不能只盯着「Thread 1」 - 启用
"showGlobalVariables": true并配合"stopOnEntry": false，避免一启动就卡在 main 入口，错过线程创建瞬间 - Linux 下若用
gdb后端，确保编译时加-g -O0，-O2会导致内联线程函数，调试器看不到独立线程帧
launch.json 中 miDebuggerPath 和 setupCommands 配置不对，线程列表为空
VSCode 的 C/C++ 扩展依赖 GDB/LLDB 正确报告线程信息。如果 threads 栏里只显示一个线程，大概率是调试器没拿到线程元数据。
-
miDebuggerPath必须指向支持 pthread 的 GDB（比如 Ubuntu 自带的/usr/bin/gdb），不是gdb-multiarch或精简版 - 在
setupCommands里加一条：{"description": "Enable thread debugging", "text": "-enable-pretty-printing"}，否则某些 GDB 版本会静默禁用线程视图 - macOS 上用 LLDB 时，
launch.json必须设"type": "lldb"，且项目需用clang++ -std=c++17 -pthread编译，否则std::thread构造不触发线程注册
断点打在 std::thread 构造函数或 lambda 内部不命中
不是断点失效，而是线程对象构造和实际执行是分离的：std::thread t{[](){...}}; 这行只是创建对象，真正执行在 t.join() 之前某个时刻——而且可能被优化掉。
- 断点优先打在 lambda 体内部第一行，而不是
std::thread构造调用处 - 避免在 release 模式下调试；
-O2可能将简单 lambda 内联为全局函数，符号名变化导致断点绑定失败 - 若用 C++20
std::jthread，注意 VSCode 1.85+ 才能正确识别其析构时的 join 行为，旧版本会误判线程已退出
调试 Python 多线程时 threading.Thread 看不到子线程堆栈
Python 扩展默认使用 ptvsd（旧）或 debugpy（新），但后者对 threading 模块的支持依赖于是否启用 subProcess 捕获——不配就只能看到主线程。
- 在
launch.json中必须加："subProcess": true，否则子线程启动后调试器无法 attach - 不要用
thread.start()后立刻thread.join()，这样线程生命周期太短，调试器来不及注入；加个time.sleep(0.1)延长窗口 - 若用
concurrent.futures.ThreadPoolExecutor，断点要打在submit的 callable 内部，而不是submit调用本身——它只是入队，不立即执行
多线程调试真正的难点不在配置，而在于「你永远不确定此刻哪个线程正运行、哪个刚被调度出去」。别依赖单次断点，多用「暂停全部线程 → 切换查看各线程调用栈 → 恢复」这个循环。线程 ID 在 VSCode 里是动态分配的，每次重启都变，记不住就别硬记。
