根本原因是系统 PATH 未包含 .NET SDK 路径，导致 VSCode 无法调用 dotnet 命令；需将 SDK 的 bin 目录（如 /usr/local/share/dotnet 或 C:\Program Files\dotnet）加入 PATH 并彻底重启 VSCode。
装完 VSCode 为什么 dotnet 命令还是找不到？
根本原因不是 VSCode 没配好，而是系统 PATH 没把 .NET SDK 路径加进去。VSCode 启动时继承的是系统 shell 的环境变量，如果你是用包管理器（比如 scoop 或 brew）装的 .NET，或者手动解压安装，dotnet 很可能根本不在 PATH 里。
- 在终端里直接运行
which dotnet（macOS/Linux）或where dotnet（Windows CMD），确认路径是否存在 - 如果没输出，说明命令不可见——这时候开 VSCode 也一样找不到
dotnet - 把 SDK 的 bin 目录（例如
/usr/local/share/dotnet或C:\Program Files\dotnet）加进系统PATH，然后重启 VSCode（不是重开窗口，是彻底退出再打开） - 验证：在 VSCode 内置终端里执行
dotnet --version，有输出才算真正就位
C# Dev Kit 插件和传统 C# 扩展有什么区别？
旧版 C# 扩展（Omnisharp）靠自己解析项目、启动语言服务；C# Dev Kit 是微软官方新栈，深度绑定 dotnet CLI 和 Roslyn，不依赖 Omnisharp，也不再需要手动配置 omnisharp.json。
- 必须已安装 .NET 7+ SDK（
C# Dev Kit不支持 .NET 6 及更早版本） - 插件启用后会自动检测
.csproj，生成.vscode/tasks.json和.vscode/launch.json（但只在首次打开项目时提示，错过就得手动触发） - 调试时默认走
dotnet run，不是启动独立进程，所以修改代码后热重载（Hot Reload）能直接生效，前提是项目启用了<iswebproject>false</iswebproject>或是 ASP.NET Core 项目 - 如果看到“Language server is not running”提示，大概率是
dotnet不在 PATH，或项目没识别出 SDK 版本（检查global.json是否锁定了不兼容版本）
新建控制台项目后按 F5 调试报错：Could not find a project to run
VSCode 默认调试配置不会自动猜你打算跑哪个项目——它只认当前工作区根目录下的第一个可执行项目，且要求项目文件里明确标记为可启动项。
- 确保你在项目根目录（即含
.csproj的文件夹）下打开 VSCode，而不是上层文件夹 - 检查
.csproj是否包含<OutputType>Exe</OutputType>，没有这行，C# Dev Kit不认为它是可运行项目 - 如果项目里有多个
.csproj（比如类库 + 控制台），VSCode 可能选错——用命令面板（Ctrl+Shift+P）运行C# Dev Kit: Select Startup Project手动指定 - 调试配置生成后，打开
.vscode/launch.json，确认project字段指向正确的.csproj文件路径，别是空字符串或拼写错误
中文路径或文件名导致调试失败或断点不命中
这不是 VSCode 或 C# Dev Kit 的 bug，而是 .NET CLI 在 Windows 上对非 ASCII 路径处理不一致造成的——尤其当路径含中文、空格、括号时，dotnet build 生成的 PDB 符号文件路径和实际加载路径不匹配。
- 最稳方案：把项目移到纯英文路径下，比如
C:\dev\myapp，彻底避开问题 - 临时绕过：在
.csproj里加<DebugType>embedded</DebugType>，让调试符号直接打进 DLL，不依赖外部 PDB 文件 - 不要依赖“用引号包住路径”这种操作——VSCode 的调试器、.NET CLI、MSBuild 三方对引号的解析逻辑不同，容易漏掉一层
- 如果已在中文路径开发，至少保证项目名、解决方案名、命名空间全用英文，减少符号混淆概率
调试器底层靠 PDB 文件映射源码行号，一旦路径编码错位，断点就只是红点，点不进去。这个问题在跨平台协作时特别隐蔽，因为 macOS/Linux 对 UTF-8 路径容忍度高，Windows 上却突然崩。
