codelldb在windows上基本不可用，因lldb官方未提供稳定windows发行版，lldb-mi已被弃用；macos下可用但需绕过gatekeeper签名限制，包括安装xcode命令行工具、手动放行lldb及清除quarantine属性。
CodeLLDB 在 macOS 上能用，Windows 上基本不能直接用——不是插件问题，是底层调试器链路不兼容。
CodeLLDB 插件在 Windows 上根本起不来
CodeLLDB 依赖原生 LLDB 调试器，而 Windows 官方不提供 LLDB 的稳定发行版。VSCode 官方 cppdbg（即 Microsoft 提供的 C/C++ 扩展）在 Windows 上默认走的是 gdb 或 msvc 调试路径，lldb 不是首选，也未被完整适配。
常见现象：
- 安装 CodeLLDB 后，
launch.json里把"type"设为"lldb"，启动调试直接报错：Cannot find debugger "lldb" - 手动指定
"miDebuggerPath"指向 Windows 下编译的 lldb-mi，大概率触发Failed to launch MI debugger或崩溃退出 - 即使凑合跑起来，变量展开、STL 容器可视化、条件断点等核心功能全部失效
根本原因：LLDB 的 Windows 支持长期停留在实验阶段，lldb-mi 已被官方标记为 deprecated，VSCode 的 CodeLLDB 插件也没做兜底适配。
macOS 下 CodeLLDB 是首选，但得绕过系统签名限制
macOS 自带 LLDB，CodeLLDB 插件开箱即用，但首次调试会卡在“无法验证开发者”——这不是插件问题，而是 Apple 对调试器进程的 Gatekeeper 限制。
必须做的三件事：
macOS 微信消息自动化工具。通过 GUI 自动化实现：发送消息给指定联系人、读取聊天内容、监控新消息。适用于需要自动化微信操作的场景，如定时发送、批量回复、消息备份等。依赖 peekaboo 进行屏幕截图和 UI 交互。仅支持 macOS。开源地址：https://github.com/chairmanmia...
- 确保已安装 Xcode Command Line Tools：
xcode-select --install，否则lldb命令本身都不可用 - 首次启动调试时，若弹出“无法打开‘lldb’，因为无法验证开发者”，不要点“取消”，点“显示在访达中” → 右键“显示简介” → 勾选“仍要打开”
- 如果用的是自定义 build 的二进制（比如从源码编译的 lldb），需手动执行：
xattr -d com.apple.quarantine /path/to/lldb
漏掉任一环，CodeLLDB 就会静默失败，VSCode 日志里只显示 Debug adapter process exited with code=0，毫无提示。
cppdbg（C/C++ 扩展）在双平台行为不一致
微软官方的 cppdbg 调试器在 Windows 和 macOS 上共用同一套配置语法，但实际行为差异极大：
- Windows 下默认使用
gdb（MinGW）或vs2019/2022（MSVC），miDebuggerPath必须指向真实可执行文件，路径含空格必须加引号 - macOS 下若没装
gdb（它不被 Apple 推荐且需手动签名），cppdbg会自动 fallback 到系统lldb，但变量查看能力远弱于 CodeLLDB -
stopAtEntry在 Windows + MSVC 下有效，在 macOS + clang 下常被忽略；externalConsole在 Windows 上弹 cmd 窗口，在 macOS 上只影响终端复用逻辑，不弹新窗口
最易踩的坑：cppdbg 的 setupCommands 里写 set follow-fork-mode child，在 macOS 上完全无效——LLDB 不认 GDB 命令，得换用 settings set target.follow-fork-mode true，否则多进程调试直接失控。
跨平台 launch.json 配置没法真正“一套通用”
想靠一个 launch.json 同时跑通 Windows 和 macOS？技术上可行，但代价高、维护难。
- 必须用
configurations+compounds分离平台逻辑，再配合when条件判断：isWindows、isMac，但这些条件只在 UI 层过滤，不会改变底层调试器行为 -
miDebuggerPath不可能同时指向C:\mingw64\bin\gdb.exe和/usr/bin/lldb，只能靠预设变量或脚本生成，VSCode 原生不支持 - 更现实的做法是：保留两套
launch.json，通过.vscode/settings.json的debug.onTaskErrors和files.associations做轻量区分，而不是硬塞进一个文件
真正麻烦的从来不是配置写法，而是当你在 Windows 上调通了 gdb 断点，切到 macOS 发现 STL vector 居然打不开——这时候才意识到，调试体验的鸿沟不在路径，而在调试器对语言特性的理解深度。
