macos上vscode插件崩溃日志路径为~/library/application support/code/logs/下的exthost*.log，需通过命令面板执行developer: open extension host log打开；若日志为空，说明崩溃发生在日志初始化前，应改用code --disable-extensions启动排查。
macOS 上插件崩溃日志路径和读取方式
VSCode 插件在 macOS 崩溃时，Extension Host 日志不存于 %APPDATA%\Code\Logs（那是 Windows 路径），也不在 VSCode 主日志目录里。Fitten Code 等独立插件甚至完全不走 VSCode 日志系统——它们写入自己专属位置：~/.local/share/fitten-code/log/。其他多数插件则统一由 VSCode 托管在：~/Library/Application Support/Code/logs/ 下的 exthost*.log 文件中。
打开方式不是靠菜单点开，而是命令面板执行：Developer: Open Extension Host Log。若该命令报错或日志为空，说明崩溃发生在日志初始化之前，必须退回终端阶段排查。
- 日志为空 → 用
code --disable-extensions启动，确认是否插件问题 - 日志末尾有
ERROR行 → 抓住at .../ms-python.python-2026.3.1/dist/extension.js这类路径，插件 ID 就是ms-python.python - 看到
spawn ENOENT或permission denied→ 插件试图调外部程序失败，常见于路径含空格、中文或权限不足
macOS 特有崩溃诱因：文件监听与路径空格
macOS 的 inotify 兼容层（kqueue）对大量小文件监听效率低，而 VSCode 默认递归监听整个工作区。一旦打开含 node_modules 的项目，files.watcherExclude 若未生效，就会持续消耗内核句柄并拖垮内存——这不是插件代码 bug，而是系统级泄漏。
另一个高频陷阱是插件 spawn 外部命令时路径被截断。比如日志里出现：spawn C:\Program Files\Python\python.exe（Windows 示例），在 macOS 上对应的是：/Applications/Visual Studio Code.app/Contents/MacOS/Electron 或 /usr/local/bin/python3 被空格或中文路径打断。
-
"files.watcherExclude"配置必须写进settings.json，且需**完全退出 VSCode（包括菜单栏图标）再重开**才生效 - 手动复现 spawn 命令前，先
cd到插件安装目录：~/.vscode/extensions/fitten.fitten-code-*，再运行日志里报错的完整命令 - 测试路径是否安全：在终端执行
which python3，然后用双引号包裹全路径再试："$(which python3)" --version
插件激活失败的 macOS 线索定位法
插件没崩溃，但功能不生效（如右下角语言标识消失、补全失效），常因 activate() 函数卡死或静默失败。macOS 上这类问题更隐蔽——因为 Electron 渲染进程对 Node.js 错误容忍度低，有时连堆栈都不输出。
比看 UI 更快的方式是交叉验证三处状态：
- 命令面板运行：
Developer: Show Running Extensions，重点关注Status为Activation failed或Activation Time > 1000ms的插件 - 打开开发者工具（
Cmd+Option+I），切到Console标签，观察是否有FATAL ERROR: Ineffective mark-compacts（内存溢出）或Cannot read property 'postMessage' of null（Webview 已销毁） - 终端执行：
ps aux | grep exthost，看进程是否存在；若存在但 CPU 为 0% 且内存不涨，大概率卡在某个同步阻塞调用（如fs.readFileSync读大文件）
调试 C++/LLDB 类插件在 macOS 的断点失效问题
macOS 下 cppdbg（原生 LLDB）和 CodeLLDB 插件都依赖系统 lldb，但行为差异明显：原生方案不支持条件断点、STL 容器可视化，而 CodeLLDB 在 M1/M2 芯片上若未装 Rosetta 2，可能因架构不匹配导致变量无法解析。
断点不命中不是配置写错，而是底层调试器未正确 attach 到进程。关键检查点不在 launch.json，而在终端输出：
- 启动调试后，立即在终端执行：
ps aux | grep lldb，确认有lldb --server进程在运行 - 若使用
CodeLLDB，检查其日志：Developer: Open Extension Host Log中是否有Failed to launch lldb-server或arm64e binary not supported - 临时禁用 SIP（仅测试）：
csrutil disable后重启，验证是否因系统完整性保护拦截了调试器注入（常见于自签名二进制）
真正麻烦的不是断点设不设得上，而是 macOS 对调试器的 sandbox 限制比 Linux 严格得多——哪怕 lldb 命令行能跑，VSCode 插件也可能因权限被拒而静默失败，这种错误只出现在 exthost 日志末尾，不会弹窗提醒。
