关键在语言服务器是否真正跑起来：haskell需haskell-language-server-wrapper、erlang需erl和rebar3、f#需dotnet fsi，这些命令必须在vscode集成终端中可调用，否则插件仅为空壳；项目须根目录打开，依赖正确配置文件，状态栏应显示对应语言标识，异常时优先查output面板日志。
函数式编程插件不是装上就灵，关键在“语言服务器是否真正跑起来”——Haskell 的 haskell-language-server-wrapper、Erlang 的 erl 和 rebar3、F# 的 dotnet fsi，这些命令必须在 VSCode 集成终端里可直接调用，否则插件只是个空壳。
确认底层工具链在 VSCode 终端中真正可用
所有函数式语言插件都依赖本地 CLI 工具提供语义能力，VSCode 本身不解析代码，只转发请求。很多“语法高亮失效”“跳转定义失败”的问题，根源是插件根本没连上后端进程。
- 在 VSCode 内置终端（不是系统终端）运行
which erl、which haskell-language-server-wrapper、dotnet fsi --version，全部必须返回有效输出 - Mac/Linux 用户若用
zsh，检查~/.zshrc是否导出 PATH；Windows 用户注意 VSCode 默认启动 PowerShell，不是 CMD，需确保rebar3.bat在 PATH 中且扩展名是真实.bat（非隐藏.txt） - 对 Erlang，
erl -eval 'crypto:start(). halt().' -noshell必须静默退出，否则pguyot.erlang插件会卡在初始化阶段
避免语言服务器启动冲突
多个同语言插件共存时，常因争抢 LSP 端口或监听路径导致功能降级。VSCode 不会自动禁用旧插件，得手动清理。
- Haskell：卸载任何带
haskell-lsp、haskell-ghc-mod字样的旧扩展，只留justusadam.language-haskell - F#：禁用所有非
Ionide的 F# 相关插件，尤其注意fsharp（已废弃）、fsautocomplete（FSAC 已整合进 Ionide） - Erlang：
pguyot.erlang是唯一支持调试的活跃维护版本，别选erlang-ls或vscode-erlang，后者不支持rebar3项目结构
项目根目录必须显式打开，不能只开单个文件
函数式语言服务器严重依赖项目上下文：Haskell 需要 stack.yaml 或 cabal.project，Erlang 依赖 rebar.config，F# 依赖 .fsproj 或 Directory.Build.props。只打开 .hs 文件，LSP 就无法加载依赖图。
- 用
stack new myproj、rebar3 new app或dotnet new console -lang F#初始化项目，再执行File → Open Folder打开整个目录 - 打开后观察右下角状态栏：Haskell 应显示
Haskell (GHCUP)，Erlang 显示Erlang，F# 显示F#；若仍为Plain Text，点击后手动关联文件类型 - 首次打开可能卡顿几秒——这是 HLS/FSAC 在构建缓存，不是卡死，别急着关掉
格式化与保存行为需按语言约定单独配
函数式语言对空格、缩进、换行极其敏感，全局启用 editor.formatOnSave 可能破坏语法结构，比如 Haskell 的 where 子句缩进错一位就编译失败。
- Haskell：关闭全局格式化，改用
"[haskell]": { "editor.formatOnSave": true }按语言启用，并指定"haskell.formattingProvider": "fourmolu"（比 brittany 更稳定） - Erlang：禁用
editor.formatOnSave，用tasks.json配rebar3 format手动触发，避免erlfmt误改守卫表达式 - F#：启用
"[fsharp]": { "editor.formatOnSave": true }，但必须设"fsharp.formattingOptions.indentSize": 4，FSI 对缩进零容忍
最易被忽略的一点：HLS、FSAC、Erlang LS 这些服务默认不打印启动日志。一旦功能异常，第一反应不该是重装插件，而是打开 VSCode 的 Output 面板，切换到对应语言标签页（如 Haskell、F#），看有没有 Failed to start server 或 Connection refused 类错误——那才是真正该修的地方。
