clion 默认使用 lldb，但需确保 debug profiles 中启用 lldb、构建含 -g 调试符号、macos 已安装 xcode 命令行工具，且避免 strip 或 lto 破坏 dwarf 信息。
CLion 默认在 macOS 和 Linux 上使用 LLDB，但需要确认工具链配置正确、调试符号可用，且没有被 GDB 或 DAP 调试器意外覆盖。手动指定 LLDB 是必要的，尤其在多工具链或交叉调试场景下。
确认当前调试器是 LLDB 而非 GDB 或 DAP
CLion 2026.2 起，调试器由 Debug Profiles 控制，不再通过工具链全局设置。即使你选了 Clang 编译器，也可能因 profile 错误而实际启用 GDB。
- 打开
Settings | Build, Execution, Deployment | Debugger | Debug Profiles - 检查当前激活的 profile 是否显示为
LLDB（不是GDB或自定义 DAP 名称） - 若 profile 缺失或错误：点击
+添加新 profile，类型选LLDB，名称如Local LLDB (Clang) - 确保该 profile 的
Debugger executable指向系统或 CLion 捆绑的lldb（例如/usr/bin/lldb或$CLION_HOME/bin/lldb/mac/lldb）
LLDB 调试必须有调试符号，且不能被 strip
LLDB 不会像 GDB 那样容忍部分缺失符号；一旦二进制被 strip 或未编译带 -g，变量名、源码行号、STL 容器展开全部失效——这不是 CLion 问题，是 LLDB 本身限制。
- 构建时务必加
-g（CMake 中设CMAKE_CXX_FLAGS_DEBUG="-g"） - 避免在构建后执行
strip ./myapp；若必须瘦身，用strip --strip-debug保留调试段 - 对于远程调试，
.debug_*段必须存在于本地机器的可执行文件副本中（LLDB 不会从目标机拉取） - 若用 CMake + Ninja，确认
cmake -DCMAKE_BUILD_TYPE=Debug已生效，且没有被CMAKE_CXX_FLAGS中的-O2覆盖掉调试信息
macOS 上 LLDB 依赖 Xcode 命令行工具，不是仅靠 clang
CLion 自带的 lldb 在 macOS 上仍需调用 Xcode 提供的运行时支持库（如 liblldb.dylib 及符号解析逻辑）。仅安装 clang 不足以让 LLDB 正常工作。
- 运行
xcode-select --install确保命令行工具已安装 - 若已装但报错
unable to find lldb framework，执行sudo xcode-select --reset - 不要手动替换
/usr/bin/lldb为旧版或自制版本；CLion 捆绑的lldb 21.1.7已针对 macOS 适配，混用易出SBValue is invalid类错误 - 检查
xcrun -f lldb输出路径是否与 CLion profile 中配置的路径一致
调试时变量不显示？优先查 expr 和 frame variable
CLion 变量视图有时因渲染策略或模板特化丢失内容，但底层 LLDB 通常能读到。别急着改 Data Views 设置，先验证数据是否真实存在。
- 调试中断后，在
Debug → Console标签页输入：expr -- (int)vec.size()—— 若返回值正常，说明符号和内存都 OK，只是 UI 渲染问题 - 输入：
frame variable --no-objc --verbose my_struct—— 查看完整字段及内存偏移，绕过自动折叠 - 右键变量 →
View as Array…输入长度，适合调试 raw buffer 或char*，比盲目展开更可靠 - 若
expr报use of undeclared identifier，大概率是编译时未带-g或头文件未被#include到当前编译单元
最容易被忽略的是：LLDB 对模板实例化符号的解析高度依赖编译器生成的 DWARF 信息质量。Clang 17+ 的 -g 默认足够，但若用了 -flto 或 -fdebug-types-section，可能破坏符号关联——这种问题不会报错，只会静默丢失变量，必须回归纯 -g 构建验证。
