LLDB找不到符号的根本原因是路径不匹配：Clang默认生成独立.dSYM目录，而launch.json中program必须为绝对路径且与.dSYM同级同名；cwd设置不当、多.dSYM干扰、第三方库无调试符号等均会导致断点灰色或变量。
LLDB 找不到符号：不是没编译，是路径没对上
VSCode 启动 lldb 后断点灰色、变量显示 <optimized out></optimized> 或直接报 no debug symbols found，大概率不是你忘了加 -g，而是 LLDB 根本没加载到正确的符号文件——它在错误的路径里找 .dSYM 或调试信息段。
- macOS 上，Clang 默认生成
.dSYM包（目录），而不是把调试信息塞进二进制；LLDB 必须能定位到这个同名目录，比如./myapp对应./myapp.dSYM -
launch.json中的"program"必须是绝对路径，且与.dSYM目录同级、同名（不含扩展）；相对路径或构建产物路径错位会导致 LLDB 完全忽略符号 - 若用 CMake 构建，确认
CMAKE_CXX_FLAGS包含-g -O0，并启用set(CMAKE_CXX_FLAGS_DEBUG "-g -O0")；否则 Release 模式下即使有-g，优化也会剥离关键符号 - 检查
.dSYM是否真存在：ls -la ./myapp.dSYM；若不存在，说明编译未触发 dSYM 生成（Xcode 工具链默认开，但命令行 clang++ 可能需要显式加-g+-fdebug-prefix-map=）
多个 .dSYM 并存时 LLDB 选错包
当项目中存在历史构建产物（如旧版 myapp.dSYM）、测试二进制（test_app.dSYM）或 CI 生成的残留符号包，LLDB 可能按字典序或 mtime 错误加载非目标包，导致断点命中但变量为空、栈帧错乱。
- LLDB 默认行为是扫描当前目录及父目录下所有
*.dSYM，不验证内部 UUID 是否匹配目标二进制 - 用命令行验证匹配性：
dsymutil -u ./myapp输出 UUID，再对比dwarfdump -u ./myapp.dSYM——两者必须一致 - 临时解决：重命名干扰项，如
mv test_app.dSYM test_app.dSYM.bak；长期方案是在launch.json中显式指定符号路径："customLaunchSettings": { "targetSymbolsPath": "./myapp.dSYM" }（需 CodeLLDB v1.11+） - CI/CD 环境下，务必在构建步骤末尾清理旧
.dSYM：find . -name "*.dSYM" -type d -not -path "./build/*" -delete
符号路径被 launch.json 的 cwd 覆盖
"cwd" 字段在 launch.json 中看似只影响工作目录，但它会改变 LLDB 解析 .dSYM 相对路径的基准点——尤其当你把构建产物放在 ./build/ 下，而 cwd 设为 ${workspaceFolder} 时，LLDB 就会在根目录找 build/myapp.dSYM，而非 build/myapp.dSYM。
macOS UI 自动化技能包 —— 用 Python 控制你的 Mac
下载
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 最稳妥写法：
"cwd": "${fileDirname}"或"cwd": "${workspaceFolder}/build"，确保与"program"路径层级一致 - 避免使用
"cwd": "${workspaceFolder}"配合"program": "${workspaceFolder}/build/myapp"——这会让 LLDB 在根目录搜build/myapp.dSYM，但实际.dSYM在build/内 - 验证方式：启动调试后，在调试控制台执行
settings show target.exec-search-paths，看 LLDB 实际搜索路径是否包含你的build/目录
第三方库符号缺失引发的“局部”符号冲突
你自己的代码能断点，但一进 libxyz.dylib 就跳过、变量不可见，甚至报 symbol not found in current context ——这不是你项目的问题，而是 LLDB 加载了无调试信息的系统或 Homebrew 库。
立即学习“C++免费学习笔记（深入）”；
- macOS 系统库（如
libc++.dylib）默认不带符号；Homebrew 安装的库（如openssl）也常只有头文件，无.dSYM - 若需调试第三方代码，优先找带
-debuginfo的包（如 Fedora 的openssl-debuginfo），macOS 下可尝试brew install --build-from-source openssl并确认生成.dSYM - 临时绕过：在
launch.json中加"ignoreWindowsSymbolLoadFailures": true（虽名含 Windows，实为通用开关），避免因外部符号缺失中断调试流 - 真正要警惕的是“符号覆盖”：两个不同版本的
libabc.dylib同时被LD_LIBRARY_PATH或@rpath引入，LLDB 可能加载了旧版（无符号）的副本；用otool -L ./myapp和dyld_info -arch x86_64 -bind ./myapp查真实加载路径
