前言
对比 Goland 和 VSCode，你会发现后者虽然看起来轻量，但效率完全不如前者，比如自动导包后，需要过好一会才能完成代码诊断，飘红的地方才能消失。而当你处理大项目的时候，跳转到定义也需要大约秒级才能反应过来。
如果你在 VSCode 上写过 Rust，你会发现 Rust-Analyzer 似乎比 vscode-go 快的不是一丁半点，诊断和跳转速度和 VSCode 自带的 js 支持差不多。有的时候我会想是不是因为 Go 自身的特性导致它写成的 lsp 后端非常 lj，但事实似乎并不是这样。
具体原因
在 github 上的 Golang 官方的镜像仓库中，我们可以在文档 design.md 找到具体原因：
警告，长篇英文
Each editor has its own plugin that shells out to a variety of tools, many of which break with new Go releases or because they are no longer maintained.
The individual tools each have to do the work to understand the code and all its transitive dependencies.
Each feature is a different tool, with a different set of patterns for its command line, a different way to accept input and parse output, a different way of specifying source code locations. To support its existing feature set, VSCode installed 24 different command line tools, many of which have options or forks to configure. When looking at the set of tools that needed to be migrated to modules, across all the editors, there were 63 separate tools.
All these tools need to understand the code, and they use the same standard libraries to do it. Those libraries are optimized for these kinds of tools, but even so processing that much code takes a lot of time time. Almost none of the tools are capable of returning results within 100ms. As developers type in their editor, multiple of these features need to activate, which means they are not just paying the cost once, but many times. The overall effect is an editing experience that feels sluggish, and features that are either not enabled or sometimes produce results that appear so slowly they are no longer useful when they arrive. This is a problem that increases with the size of the code base, which means it is getting worse over time, and is especially bad for the kinds of large code bases companies are dealing with as they use Go for more major tasks.