必须手动配置haskell.serverexecutablepath为wrapper路径，如windows填d:\ghcup\bin\haskell-language-server-wrapper.exe、macos/linux填~/.ghcup/bin/haskell-language-server-wrapper；项目根目录须含.cabal或stack.yaml，且必须通过“open folder”打开，否则hls无法启动类型服务。
haskell.serverExecutablePath 必须手动填 wrapper 路径
VSCode 的 Haskell 插件（ID: Haskell.haskell）默认会尝试自动找 haskell-language-server-wrapper，但国内网络环境下几乎必失败——它不走镜像源，也不报错，只是静默降级为仅语法高亮。结果就是悬停没类型、Ctrl+Click跳转失效、错误不标红。
解决方法是硬编码路径：
- Windows：打开设置搜索
haskell.serverExecutablePath，填入类似D:\ghcup\bin\haskell-language-server-wrapper.exe - macOS/Linux：填入
~/.ghcup/bin/haskell-language-server-wrapper（不确定？终端跑which haskell-language-server-wrapper） - 千万别填
haskell-language-server—— 它绑定死 GHC 版本，wrapper 才能根据项目自动选对版本
项目根目录必须含 .cabal 或 stack.yaml
HLS 不识别单个 .hs 文件，也不加载空文件夹。你打开一个 Main.hs，右下角显示 “Loading…” 卡住，大概率是因为没项目结构。
两种最低要求的合法结构：
- 新建
hello.cabal（哪怕只写三行：name: hello、version: 0.1.0、executable hello） - 或建
stack.yaml（内容可极简：resolver: lts-22.29） - VSCode 必须用
File → Open Folder打开该目录，不能Open File
类型推导失效常见原因与验证方式
即使路径和项目结构都对，类型提示仍可能不出现。先快速验证 HLS 是否真在跑：
- 打开命令面板（
Ctrl+Shift+P），运行Haskell: Restart Haskell Language Server - 看输出面板（
Output → Haskell）有没有类似Started haskell-language-server-wrapper和Session loading result: Success - 如果报
Failed to parse cabal file，说明.cabal格式有误；报No targets to load，说明 HLS 没找到可构建目标（比如 executable 名字没对上） - 悬停函数名时，若只显示
unknown type，大概率是 GHC 版本与 HLS 不匹配——用ghcup list查已装 HLS 版本，再ghcup set hls <version></version>显式指定
runhaskell 与 HLS 类型推导完全无关
很多人混淆“运行”和“类型服务”。runhaskell 是解释器，只负责执行，不提供任何类型信息；HLS 是语言服务器，依赖项目构建上下文做静态分析。
所以：
- 用
tasks.json配runhaskell ${file}跑单文件，HLS 依然不会启动——除非这个.hs在合法项目里 - 想让
Main.hs有完整类型提示，它得是.cabal里声明的main-is:目标，或stack.yaml中packages:列出的模块 - 别指望在没
.cabal的文件夹里靠改haskell.serverExecutablePath就唤醒类型推导——结构断了，wrapper 再准也没用
最常被忽略的一点：HLS 启动后要解析整个依赖图，首次打开项目可能卡住 10–30 秒，状态栏没反应不等于失败。等 Output → Haskell 出现 Session loading result: Success 才算真正就绪。
