<p>C# Dev Kit 是 VS Code 调试 C# 的必要前提，需精确搜索安装、重启 VS Code、指定 .NET SDK 路径，并通过文件夹方式打开含 .csproj 或 .sln 的项目才能激活全部功能。</p>
VS Code里搜不到 C# Dev Kit 怎么办
不是插件没上架，而是你可能输错了关键词或网络没加载完。C# Dev Kit 是微软官方打包发布的扩展，名字就是 C# Dev Kit，不是 “C#” “C Sharp” 或 “C# Extension”。如果搜索后列表为空，先检查 VS Code 是否已联网，再确认扩展市场没有被代理或防火墙拦截。
实操建议：
- 按
Ctrl+Shift+X（Windows/Linux）或Cmd+Shift+X（macOS）打开扩展面板 - 在搜索框中**精确输入
C# Dev Kit**（注意空格和大小写，首字母大写） - 认准发布者是 Microsoft，图标为蓝白相间的“#”符号
- 点击安装后必须重启 VS Code，否则语言服务不会激活
装了 C# Dev Kit 还要单独装 C# 扩展吗
不用。C# Dev Kit 是一个“元扩展”，它会自动拉取并启用 C#（即 OmniSharp 提供的语言服务）、.NET Runtime Install Tool 和 IntelliCode 三个依赖项。如果你之前单独装过旧版 C# 扩展，VS Code 通常会在安装 C# Dev Kit 后禁用它——这是正常行为，不是出错。
验证是否生效：
- 新建一个
.cs文件，看是否有语法高亮和using System;的智能提示 - 打开命令面板（
Ctrl+Shift+P），输入.NET: Create Console App，能出现即说明核心服务就绪 - 终端执行
dotnet --version成功，但编辑器里仍无提示 → 很可能是dotnet没加进系统 PATH，不是插件问题
macOS 或 Linux 上 C# 插件调试失败的常见卡点
不是插件装错了，而是权限或路径配置没跟上。尤其 macOS 用户容易在调试时遇到 Could not find coreclr 或 Permission denied，根源常在 /usr/local/share/dotnet 目录未被 VS Code 继承访问权。
关键动作：
- 确保
dotnet命令在终端任意目录下都可执行（不只是当前项目目录） - macOS 用户需在 Docker Desktop 的 Preferences → Resources → File Sharing 中，把
/usr/local/share/dotnet/sdk/nugetfallbackfolder加入共享路径（即使没用 Docker，某些调试器也会读这个） - Linux 用户若用 snap 安装的 VS Code，它默认无法访问
/usr/share/dotnet，建议改用.tar.gz版本或手动设置DOTNET_ROOT环境变量 - 调试前务必先运行
dotnet build，否则launch.json里写的${workspaceFolder}/bin/Debug/net8.0/xxx.dll路径根本不存在
为什么刚装完插件，打开 .cs 文件还是没提示
插件装了 ≠ 服务启动了。C# Dev Kit 依赖 OmniSharp 后端进程加载项目结构，而这个过程需要明确的项目上下文。纯文本文件、没 .csproj 的目录、或者项目 SDK 版本太老（如 netcoreapp3.1 且没装对应 SDK），都会导致语言服务静默失败。
快速验证路径：
- 用
dotnet new console -n testapp新建一个项目，再用 VS Code 打开该文件夹（不是单个 .cs 文件） - 观察右下角状态栏：出现
.NET SDK: 8.0.x和OmniSharp: Running才算真正就绪 - 如果卡在
OmniSharp: Starting...超过 30 秒，大概率是项目文件损坏或dotnet restore没跑成功，删掉obj和bin目录重试 - 别依赖“自动提示安装推荐扩展”——VS Code 有时会推错版本，比如推荐已废弃的
C# Extensions而非C# Dev Kit
插件本身只是入口，真正的语言服务活在 dotnet 和项目结构里。很多“插件没反应”的问题，其实差的是一次干净的 dotnet new 和一次正确的文件夹打开方式。
