VSCode用CodeLLDB调试Rust需确保rust-src组件已安装、Cargo.toml中[profile.dev] debug=true启用调试符号、LLDB路径指向Homebrew新版（如/opt/homebrew/bin/lldb），且launch.json中type为"lldb"、使用cargo块而非program、preLaunchTask正确关联build任务。
VSCode 用 CodeLLDB 调试 Rust，能直接看到 Vec、HashMap、Result 的内部结构，但前提是调试符号完整、LLDB 版本兼容、rust-src 组件就位——缺一不可。
为什么你的 dbg! 显示正常，但断点进不去或变量显示为 <error reading variable>
这不是代码问题，而是调试元数据链断裂。常见原因有三个：
-
rust-src组件未安装：LLDB 需要标准库源码才能解析std::vec::Vec这类类型定义，运行rustup component add rust-src补齐 -
Cargo.toml中禁用了调试信息：检查[profile.dev]段，确保debug = true（默认开启，但若手动设为false或被 workspace 继承覆盖就会失效） - LLDB 不支持当前 Rust 的 DWARF 版本：macOS 用户尤其要注意，系统自带的
/usr/bin/lldb往往太旧，必须用 Homebrew 安装新版 LLVM：brew install llvm，然后在.vscode/settings.json中显式指定路径："lldb.executable": "/opt/homebrew/bin/lldb"（Apple Silicon）或/usr/local/bin/lldb（Intel）
launch.json 配置里最关键的三项参数
VSCode 的调试行为高度依赖这三个字段，错一个就可能加载失败或断点不命中：
-
"type": "lldb"：不能写成"cpp"或留空，否则会 fallback 到 GDB 后端，对 Rust 泛型支持极差 -
"cargo": { ... }块比"program"更可靠：它让 CodeLLDB 直接调用cargo build，自动处理包名、bin 名、feature 开关；示例中"filter": {"name": "my_bin", "kind": "bin"}可精准定位二进制，避免target/debug/下多个可执行文件混淆 -
"preLaunchTask": "cargo build"必须对应.vscode/tasks.json中已定义的任务，且该任务需含"group": "build"，否则 VSCode 不识别为构建任务，调试前不会自动编译
调试 unsafe 块和裸指针时，LLDB 怎么看内存布局
普通变量查看不够用，得切换到内存视角。在断点停住后：
- 用
memory read -f x -s 8 -c 4 $rdi（x86_64）或memory read -f x -s 8 -c 4 $x0（ARM64）读取寄存器指向的 4 个 8 字节内存单元，验证*ptr as *const u8是否按预期布局 - 对
Box<T>或Rc<T>，先用frame variable --show-globals查出指针地址，再用memory read -t T -c 1 <addr>强制按类型T解析内存内容 - 注意：LLDB 默认不展开
UnsafeCell<T>内部，需手动执行expr -- (&*(0x12345678 as *const std::cell::UnsafeCell<i32>)).get()才能看到原始值
最常被忽略的是 split-debuginfo 配置——macOS 上不设 "unpacked"，LLDB 加载大型 HashMap 时会卡住数秒；Linux 上设了反而拖慢，得按平台区分。这玩意儿不报错，只悄悄变慢，等你调试并发死锁时才意识到不对劲。
