CodeLLDB调试失败需依次验证LLDB路径配置、launch.json有效性、禁用冲突扩展、启用日志定位错误、重装扩展并清除缓存。
LLDB 调试在 VSCode 里不是“装了插件就能用”，关键得让 CodeLLDB 找到真实可用的 lldb 二进制，并且 launch.json 指向带调试符号的可执行文件——缺一不可。
确认系统里真有能跑的 lldb
VSCode 的 CodeLLDB 扩展本身不带调试器，它只是个“遥控器”，必须连上本地真实的 lldb 进程。很多人卡在这一步却以为是插件坏了。
- 打开终端，直接运行
lldb --version；如果报command not found，说明没装或没进PATH - macOS 用户优先用 Homebrew 安装：
brew install llvm，然后确认/opt/homebrew/bin/lldb（Apple Silicon）或/usr/local/bin/lldb（Intel）存在 - 别信 Xcode 自带的
/usr/bin/lldb—— 它常因系统更新变砖，尤其在 macOS Sequoia 上兼容性不稳定 - 装完后，在 VSCode 设置里搜
codelldb.lldbExecutable，手动填入你验证过的完整路径，比如/opt/homebrew/opt/llvm/bin/lldb
launch.json 必须满足三个硬条件
配置写得再漂亮，只要 program 路径错、type 不对、或没调试符号，断点就永远灰着。
-
"type"字段必须是"lldb"（不是"cppdbg"，那是 C/C++ 扩展用的） -
"program"必须是**已编译好、带-g的可执行文件绝对路径**，例如"${workspaceFolder}/build/myapp"；"./main"这种相对路径在某些工作区下会失效 - Rust 用户额外注意：
cargo build默认不生成调试信息，要加--debug或确保[profile.dev] debug = true在Cargo.toml里 - 如果你用 Clang 编译，记得加
-O0 -g，避免内联导致断点跳转错乱
为什么断点不命中？先关掉这些扩展
VSCode 允许多个调试器注册同一类型，但实际只能有一个接管。C/C++ 扩展的 cppdbg 会悄悄劫持 lldb 类型，导致 CodeLLDB 启动无声无息。
- 打开扩展面板，搜索
C/C++，点击右下角齿轮 → Disable Workspace（不是卸载） - 顺手禁用
Native Debug和Debug Adapter for C/C++，它们也爱抢协议端口 - 禁用后必须重启整个 VSCode 窗口（Cmd+Q 再打开），仅重载窗口不够
- 如果仍不行，在命令面板运行
LLDB: Toggle Log，然后看输出面板里LLDB标签下的错误——常见如Failed to launch lldb process就是路径或权限问题
调试指针和内存问题不能只靠 print ptr
LLDB 默认显示太简略，print vec 只告诉你 size=5，根本看不出越界；print ptr 只打地址，悬垂指针照样显示“有效”。
- 在项目根目录建
.lldbinit，加这三行：settings set target.max-string-summary-length 1024settings set target.debugging-format dwarftype summary add -x "std::.*" --summary-string "${var}" - 查野指针时，别只信
print ptr，改用：memory read -f x -c 1 $rdi（看寄存器指向内存是否已释放） - ASan 报错后想进现场调试？别在集成终端里跑——设
"externalConsole": true，等 ASan 崩溃打出栈之后，再开终端手动lldb ./myapp→process attach --pid XXX
最易被忽略的一点：CodeLLDB 的日志开关 LLDB: Toggle Log 不是摆设，它输出的是调试器进程启动全过程，90% 的“无法启动”问题靠它三行内定位；而很多人连日志都没开过就去重装插件。
