rust-analyzer调试无需绑定F5到cargo run；F5默认报错因无launch配置，真正需配置的是launch.json中program路径（分平台加.exe）、启用clippy保存检查，并手动设断点观察move语义。
rust-analyzer 调试快捷键必须绑定到 cargo run 而非 cargo build
VSCode 默认不提供 Rust 专属调试快捷键，F5 会直接报错“no launch configuration”，因为 rust-analyzer 本身不负责运行，只负责分析。真正能触发「带所有权错误提示的实时调试流」的，是把 F5 绑定到 cargo run 并启用 checkOnSave.command = "clippy"。
这样做的原因：Clippy 能在保存时就捕获 use of moved value、value borrowed here after move 这类所有权违规，比等 cargo run 报错更早；而 cargo run 启动后，调试器（CodeLLDB 或 cppvsdbg）才能加载符号，看到变量生命周期栈帧。
- 打开
keybindings.json（Ctrl+Shift+P → “Preferences: Open Keyboard Shortcuts (JSON)”） - 添加如下条目（覆盖默认 F5 行为）：
{ "key": "f5", "command": "workbench.action.terminal.sendSequence", "args": { "text": "cargo run\u000D" }, "when": "editorLangId == rust && !inDebugMode" } - 同时确保
settings.json中有："rust-analyzer.checkOnSave.command": "clippy"
调试时按 F11 单步进入会跳过所有权转移点？
这是 CodeLLDB 的默认行为：它把 let x = y 这类绑定视为“无副作用语句”，直接跳过。但所有权转移（move）恰恰发生在这一行——比如 let s2 = s1 后 s1 就不可用了，可调试器不在这儿停。
解决办法不是改快捷键，而是加断点前手动展开表达式：
- 在
let s2 = s1;这行左侧 gutter 点击设断点（不是用 F9） - 运行调试后，停住时在 Debug Console 输入：
print s1—— 会显示error: use of moved value，证明 move 已发生 - 若想观察 move 前状态，在上一行（如
let s1 = String::from("hello");）设断点，再用F11步入String::from内部看堆分配
launch.json 中 program 路径写错导致调试器找不到可执行文件
Windows 和 Unix 系统下生成的二进制路径不同，但 VSCode 的 ${workspaceFolderBasename} 变量不会自动补 .exe 后缀。常见错误是写成："${workspaceFolder}/target/debug/${workspaceFolderBasename}"，结果在 Windows 下找不到文件。
正确写法必须分平台判断：
- Windows：
"${workspaceFolder}/target/debug/${workspaceFolderBasename}.exe" - macOS/Linux：
"${workspaceFolder}/target/debug/${workspaceFolderBasename}" - 更稳妥的做法：在
launch.json的configurations数组里定义两个配置，用when条件区分：isWindows/!isWindows
否则你会看到错误：Could not find the debug adapter executable 或更误导的 Cannot launch program; setting 'program' is not set。
调试泛型函数时变量名显示为 _ 或乱码？
这是 rustc 编译时未保留泛型符号信息导致的，不是快捷键或插件问题。默认 cargo build 使用 debug profile，但会 strip 部分类型元数据。
临时解决（开发期）：
- 在
Cargo.toml中添加：[profile.dev] debug = true debug-assertions = true
- 运行
cargo clean && cargo build重建符号表 - 重启 VSCode（rust-analyzer 缓存有时不刷新泛型推导）
这会让 Vec<u8> 显示为具体类型而非 core::vec::Vec<T>，对理解借用检查器如何推导生命周期至关重要——比如你才能看清为什么 &Vec::as_slice() 在循环中被多次借用。
