VSCode 本身不运行 F# 代码，它充当的是编辑器和交互界面，真正的执行工作靠的是 dotnet 和 dotnet fsi。

只要你的 dotnet --version 输出的是 8.0.x 或 9.0.x，而且文件后缀名是 .fsx 或 .fs，整个流程就能跑起来。

很多时候，卡住的问题不在 VSCode 本身，而是本地 .NET 环境或 Ionide 插件配置没对上。

怎么验证？ 这里有几个关键环节。一个一个排查，基本就能解决问题。

先确认整体判断

排查这类问题时，先记住一个核心点：真正决定 F# 能不能运行的，是本地 .NET 环境和 Ionide 是否正常协作。

因此，不要一开始就反复重装 VSCode。先检查 dotnet、dotnet fsi、文件识别状态，以及 FSAC 是否成功连接。

dotnet fsi --version 报 command not found？说明 SDK 装得不完整

Ionide 的 Alt+Enter、右键菜单里的 Execute in F# Interactive，这些功能全部依赖 dotnet fsi 这个可执行文件。

它并不是一个独立的工具，而是随 .NET SDK 附带的一个组件。但问题在于，某些安装方式会把它漏掉：

• macOS 用户通过 Homebrew 安装的 dotnet-sdk，默认是不包含 fsi 的。必须去微软官网下载 .pkg 安装包才行。

• Windows 上，如果用 Visual Studio Installer 安装 SDK，但没有勾选 .NET desktop development 工作负载，fsi 也不会被包含进来。

• Linux 用户如果图省事，用 apt 或 dnf 安装了精简版的 runtime（比如 aspnetcore-runtime），同样会缺少 fsi。

验证方式很简单： 直接在终端里执行 dotnet fsi --version。

如果这条命令报错，那先别折腾插件，果断重装 SDK。去 dotnet.microsoft.com/download 下载 .NET 8 SDK (LTS) 或 .NET 9 SDK。

注意是 SDK，不是 “Runtime”，也不是 “Preview” 版本。只有完整的 SDK 才会包含 dotnet fsi。

Alt+Enter 没反应？检查状态栏语言模式和 FSAC 连接状态

Alt+Enter 是 Ionide 触发 dotnet fsi 的快捷键，但它要生效，需要满足两个前提条件：

• 当前文件被正确识别为 F#

• 后台的语言服务（FSAC）已经成功连接

先看文件语言模式

打开一个 .fsx 文件后，看一眼 VSCode 窗口右下角。这里必须显示 F#，而不是 Plain Text。

如果显示的是后者，点击它，然后选择 Configure File Association for '.fsx' → F# 来手动关联。

再看 FSAC 是否启动成功

如果右下角短暂显示 Starting F# Language Service 然后消失了，说明 FSAC 启动失败了。

这时需要打开 VSCode 设置，搜索 FSharp.fsacRuntime，并将其设为 net。注意不是 netcore，那个选项已经弃用了。

改完设置后，必须关闭所有 .fs 或 .fsx 标签页，然后再重新打开文件。

仅仅重启 VSCode，是不会重置 FSAC 进程的。

用日志确认是否真的连上

更稳妥的排查方式，是在 VSCode 底部面板切换到 Output → F# Language Service 查看连接日志。

只有出现 Connected 字样，才算真正准备就绪。

想直接运行 .fsx 脚本？终端里用 dotnet fsi 更可靠

VSCode 里的交互式执行，有时会受到 FSAC 状态的影响。相比之下，直接在终端里跑命令更底层，也更稳定。

对于脚本文件，优先使用：

dotnet fsi hello.fsx

这条命令会一次性执行完整个文件，不会启动交互式会话。

它非常适合用于 CI 自动化，或者快速验证某段逻辑。

使用时要注意的细节

• dotnet fsi 支持 #load "other.fsx" 和 #r "nuget: Newtonsoft.Json" 这样的指令，但这些指令只在交互式上下文，也就是通过 Alt+Enter 启动的窗口中才生效。直接用 dotnet fsi script.fsx 的方式运行，是不会解析这些指令的。

• 如果脚本依赖了外部的 NuGet 包，建议转成正式的项目结构：用 dotnet new console -lang F# 创建一个项目，把逻辑移到 Program.fs 里，然后用 dotnet run 来执行，这样才是最稳妥的。

• dotnet fsi 默认使用的是当前生效的 SDK 版本，它不会去读取 global.json 文件。如果你的机器上有多个 .NET 版本共存，先通过 dotnet --version 确认一下当前使用的是哪一个。

断点调试不命中？launch.json 需匹配项目结构

F# 的调试走的是 .NET 的通用调试协议。

但 launch.json 里 program 字段指向的，必须是编译后的可执行文件，比如 bin/Debug/net8.0/myapp.dll，而不是源码文件。

重点检查这几项

• 确保项目已经成功构建：执行 dotnet build 之后，检查 bin/Debug/ 目录下是否有对应的框架目录和 .dll 文件。

• launch.json 中的 program 路径要写成相对路径，例如 "${workspaceFolder}/bin/Debug/net8.0/MyFSharpApp.dll"。不能写成 MyFSharpApp.fsproj 或 Program.fs 这种形式。

• 断点只能打在可执行的语句上，比如 printfn 所在的行，或者函数调用的那一行。模块定义、没有副作用的顶层 let 绑定，这些地方是无法命中断点的。

其实，对 F# 来说，最省事的调试方式，是先用 Alt+Enter 把关键函数送进 FSI，在交互式环境里分段验证逻辑，然后再整合到正式项目里。

F# 的不可变性让这种“分段验证”的方式，比传统的断点调试效率更高。

推荐的排查顺序

最后补充一个最容易踩坑的地方：FSAC 的连接状态是不会主动报错的，它只会静默地失败。

如果右下角没有显示 F# 或者 F# Ready，那整个环境就相当于没通电，其他所有操作都是白费功夫。

所以，验证的顺序永远是：

• dotnet --version

• dotnet fsi --version

• 状态栏语言模式

• F# Language Service 输出日志

按这个顺序走一遍，基本能定位到绝大多数问题。