VS Code扩展装完没反应，主因是未启用、依赖缺失、工作区限制或被设置压制；需确认启用状态、重启窗口、检查语言模式、验证CLI路径、排查冲突及查看开发者工具报错。
VS Code 扩展装完没反应，大概率不是扩展坏了，而是它根本没启动成功——常见原因包括未启用、依赖缺失、工作区限制、或被其他扩展/设置压制。
扩展显示已安装但功能不生效
先确认它是否真的处于启用状态：打开 Extensions 视图（Ctrl+Shift+X），搜索该扩展，看右下角是否显示 Disable 按钮；如果显示 Enable，说明它当前是禁用的。点击启用后，**必须重启 VS Code 窗口**（不是仅重载窗口）才能让多数扩展真正加载。
- 某些扩展（如
ESLint、Prettier）只在特定语言模式下激活，检查当前文件是否匹配其activationEvents（比如打开一个.js文件才能触发 ESLint） - 右键扩展 →
Extension Settings，确认没有误勾选Disable extension in this workspace - 打开命令面板（
Ctrl+Shift+P），输入Developer: Toggle Developer Tools，切换到Console标签页，看是否有红色报错（例如Cannot find module 'xxx'或Activation failed）
扩展依赖的 CLI 工具未正确配置
像 ESLint、prettier、rust-analyzer 这类扩展，本身不带运行时，需要你本地安装对应 CLI 并确保能在终端中调用。VS Code 启动时不会自动读取你的 shell 配置（如 ~/.zshrc），所以即使终端里能跑 eslint --version，VS Code 内置终端也可能找不到。
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 在 VS Code 内置终端中执行
which eslint或eslint --version，验证是否可访问 - 如果失败，优先尝试在 VS Code 设置中显式指定路径：搜索
eslint.packageManager或eslint.runtime，填入绝对路径（如/usr/local/bin/node）或设为npm/yarn - macOS 用户特别注意：GUI 应用（包括 VS Code）默认不加载 shell 的
PATH，可考虑用launchctl setenv PATH "..."修复，或改用code --no-sandbox启动调试
扩展与当前工作区或文件类型不匹配
VS Code 是按语言模式（language mode）和文件路径来决定是否激活扩展的。比如 Python 扩展默认只对 .py 文件生效，且要求工作区根目录下有 pyproject.toml 或 requirements.txt 才启动 LSP 服务。
- 检查右下角状态栏的语言标识（如
Plain Text），点击它并选择正确的语言模式（如Python） - 打开命令面板，运行
Developer: Inspect Editor Tokens and Scopes，确认当前文件的languageId是否与扩展期望的一致 - 某些扩展（如
GitLens）默认禁用远程开发场景，若你在 SSH/WSL 容器中工作，需检查其设置项gitlens.advanced.remote
扩展冲突或被全局设置屏蔽
VS Code 允许通过 "extensions.ignoreRecommendations"、"extensions.autoUpdate" 等设置控制行为，而更隐蔽的是 "workbench.startupEditor" 或 "editor.codeActionsOnSave" 类设置可能覆盖扩展的默认行为。
- 打开设置（
Ctrl+,），搜索扩展名，逐项检查是否被手动关闭了关键开关（如eslint.enable、prettier.enable） - 临时禁用所有其他扩展（右键 →
Disable All Extensions），再逐个启用排查冲突 - 尝试用命令行启动干净环境：
code --disable-extensions --user-data-dir=/tmp/vscode-test，排除用户配置干扰
最常被忽略的一点：VS Code 的扩展生命周期依赖于主进程与渲染进程通信，而某些杀毒软件、企业策略或自定义 shell 启动脚本会拦截或延迟该通信——如果上述都试过仍无反应，直接查看 Developer Tools → Console 里的第一行错误，比猜更可靠。
