c++oding="utf-8" ?>
根本原因是未编译调试信息或路径错误：c++需用-g编译（如g++ -g -o hello hello.cpp），lldb启动时传可执行文件（./hello）而非源码，makefile需含cxxflags+=-g，macos建议用clang，-o0禁优化，断点优先用-n main，变量不可见说明调试信息缺失。
lldb 启动时提示 No such file or directory 怎么办
根本原因通常是没编译出调试信息，或者路径写错了。C++ 源码必须用 -g 编译，否则 lldb 加载不到符号表，连 main 都找不到。
- 确认编译命令包含
-g：比如g++ -g -o hello hello.cpp，不能只写g++ -o hello hello.cpp - 启动 lldb 时传的是可执行文件路径，不是源文件：
lldb ./hello，不是lldb hello.cpp - 如果用了
make，检查 Makefile 是否漏掉了CXXFLAGS += -g - macOS 上用 Clang 编译更稳妥，某些 GCC 版本生成的 DWARF 格式可能和系统 lldb 兼容性差
设置断点但 run 后不中断，或显示 breakpoint not resolved
说明符号没加载成功，或者断点位置不可达——常见于内联函数、优化代码、或断点打在了没被编译进最终二进制的代码段上。
- 先运行
target list看是否已加载目标；再用image list确认可执行文件和调试信息都正常映射 - 用
breakpoint set -n main比breakpoint set -f main.cpp -l 10更可靠，尤其对未优化代码 - 如果用了
-O2或更高优化级，函数可能被内联或删掉，断点自然失效；调试阶段务必加-O0 - macOS 上遇到断点不命中，试试
settings set target.experimental.enable-objc-exceptions true（虽是 Objective-C 相关，但有时影响 C++ 异常处理链）
想看变量值却显示 couldn't get a value 或 no location
这是调试信息丢失最典型的信号，不是 lldb 不会查，而是编译器根本没告诉它这个变量在哪存着。
- 局部变量在函数末尾或作用域外无法访问，lldb 不会“猜”你想要什么，
print x前先frame info确认当前栈帧合法 - 结构体成员若显示
<optimized out></optimized>，基本等于提醒你：关掉优化重编译，别硬扛 - std::string、std::vector 这类类型，直接
print my_str可能只显示地址；用expr -O -- my_str（-O表示调用operator）能拿到可读内容 - Linux 下若用 libc++ 而非 libstdc++，某些 STL 类型的 summary 不会自动加载，需手动
command source /path/to/lldb/libcxx.py
调试多线程程序时 thread list 显示不全，或 step 卡死
lldb 默认不主动追踪所有线程状态变化，尤其在线程刚创建/退出的瞬间容易“丢帧”，这不是 bug，是设计取舍。
- 启动前加
settings set target.thread-step-avoid-regexp ".*"可避免 step 时意外跳进系统库 - 用
thread select N切换后，再bt才能看到该线程真实调用栈；不要只依赖bt当前默认线程 - macOS 上 pthread_create 创建的线程可能延迟出现在
thread list中，等 1–2 秒再查，或加process handle -s false -n false -p true SIGUSR1（避免信号干扰） - Linux 下建议用
lldb --batch -x "run" -x "thread list" ./myapp快速抓快照，交互式调试时线程状态易受步进节奏干扰
真正卡住的地方往往不在命令本身，而在编译选项和符号完整性——哪怕只漏一个 -g，后面所有操作都在和“看不见的变量”较劲。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
