必须加-g编译生成调试信息，否则lldb无法映射源码、显示变量；核心命令为file、b、r、n、p；多文件/CMake项目需全局启用-g和Debug模式。
Clang 安装后不能直接调试，必须加 -g 编译出带调试信息的二进制文件，再用 lldb（或 gdb）加载运行。 否则 lldb 会报 No such file or directory 或无法显示源码行、变量值为空。
编译时必须加 -g，否则调试器看不到源码和变量
Clang 默认不嵌入调试信息，lldb 依赖这些信息映射机器指令到源代码行、解析类型、读取局部变量。漏掉 -g 就像给导航仪塞一张白纸地图。
-
clang -g main.c -o main：正确，生成可调试的main -
clang main.c -o main：错误，lldb ./main能启动但l（list）命令报错，p var显示(int) $0 = 0之类无意义值 - 多文件项目中，每个
.c都要加-g；用CMake时需确保CMAKE_BUILD_TYPE是Debug（而非Release）
lldb 常用调试命令不是“高级功能”，而是基础操作流
不用记全，掌握 5 个核心命令就能覆盖 90% 单步调试场景。它们是线性执行逻辑，不是独立技巧：
-
file ./main：加载可执行文件（必须第一步） -
b main.c:12：在main.c第 12 行设断点（b是breakpoint set的缩写） -
r：运行程序，停在第一个断点 -
n：逐行执行（step over），不进入函数内部 -
s：逐指令/逐函数执行（step into），遇到函数调用就跳进去 -
p var_name：打印变量当前值（po仅对 Objective-C 对象有效，C 里一律用p）
CMake 项目里调试失败，大概率是构建类型或编译器没配对
VSCode 或 CLion 中点击「调试」按钮却跳不到断点？常见原因不是 IDE 配置错，而是底层构建没生效：
- 检查
CMakeLists.txt是否有set(CMAKE_BUILD_TYPE Debug)，或使用预设时是否选了debug类型（如configurePresets中"cacheVariables": {"CMAKE_BUILD_TYPE": "Debug"}） - 确认
CMAKE_C_COMPILER真的指向clang：运行cmake --build build --verbose | head -n 5，看实际调用的是不是/usr/bin/clang -g ... - CLion 用户注意：
Build > Recompile（Shift+Ctrl+F9）不会重新应用-g，必须Build > Rebuild Project或删掉cmake-build-debug目录再重载
AddressSanitizer 不是调试器，但能暴露 lldb 查不到的问题
内存越界、泄漏、重复释放这类问题，lldb 本身不报错——它只管执行流程，不管内存是否合法。这时候要换工具链：
-
clang -fsanitize=address -g -o prog prog.c：启用 ASan 并保留调试符号 -
./prog运行，崩溃时直接输出错误类型、栈帧、分配位置（比如heap-use-after-free） - ASan 报告里的行号可直接在
lldb里用l main.c:42定位，再结合p查变量状态 - 注意：ASan 会显著拖慢运行速度，仅用于排查阶段，别长期开着跑性能测试
真正卡住的地方往往不是命令记不全，而是编译阶段没埋下调试信息，或者以为「启动了调试器」就等于「能调试」——其实只是开了个壳子，里面没地图、没路标、也没坐标系。
