为什么要用 gopls 替换 gocode？（gopls 的核心优点）

[mowangshuying]

为什么要用 gopls 替换 gocode？（gopls 的核心优点）

官方维护与现代特性支持

• gopls：是 Go 官方团队开发的语言服务器（LSP），与 Go 语言特性同步演进。它能完美支持 Go Modules、泛型（Go 1.18+） 等现代 Go 语言的核心特性。
• gocode：已经处于维护模式，不再积极开发。它不支持泛型推导，对 Go Modules 的支持也不如 gopls 完善，面对新版 Go 的特性经常会“罢工”。

更精准的上下文感知补全

• gopls：作为语言服务器，它会在后台持续分析你的整个项目（包括抽象语法树 AST、类型系统和依赖关系）。这意味着它能提供跨文件、跨包的精准补全，甚至在你还没导入某个包时，就能智能提示并自动帮你添加 import 语句。
• gocode：虽然响应极快（号称 30ms），但它更多是基于当前文件的上下文进行推断，在处理大型项目或复杂依赖时，补全的准确率和深度远不如 gopls。

统一的开发体验（LSP 协议）

• gopls：遵循语言服务器协议（LSP）。无论你使用的是 VS Code、Vim、Neovim 还是 GoLand，只要编辑器支持 LSP，就能获得完全一致且强大的智能体验（包括代码跳转、查找引用、重命名重构、实时错误诊断等）。
• gocode：只是一个单纯的“自动补全守护进程”。如果你想实现跳转定义、重构等功能，还得额外去配置 guru、godef 等其他零散工具，不仅繁琐，而且不同工具之间的体验割裂严重。

实时诊断与静态分析

• gopls：能在你敲代码的同时，实时在后台进行编译检查和静态分析（如检测未使用的变量、可能的 nil 指针引用等），无需手动执行 go build 就能提前发现 90% 的常见 Bug。
• gocode：仅专注于补全，没有内置强大的实时诊断和静态分析能力。

gopls 有什么缺点吗？

客观来说，gopls 并非完美，它的“缺点”主要体现在对硬件资源的要求上：
资源占用较高：由于 gopls 需要在后台深度解析整个项目的代码结构和依赖，它在处理超大型项目时，启动初期的内存和 CPU 占用会比轻量的 gocode 高。
配置相对复杂：对于极度轻量化的编辑器（如纯终端 Vim），配置 gopls 比直接调用一个 gocode 二进制文件要稍微麻烦一点（不过现在主流的 vim-go 等插件都已经实现了自动化配置）。
视情况而定的替换建议

必须替换的情况：

如果你正在使用 Go 1.18 及以上版本（特别是用到了泛型），或者你的项目使用了 Go Modules 进行依赖管理，那么请立刻、马上替换为 gopls。继续使用 gocode 会导致大量补全失效或提示错误。
强烈建议替换的情况：如果你希望获得现代化的 IDE 体验（如智能重构、精准的跨包跳转、实时错误波浪线提示），gopls 是目前唯一且最佳的选择。
唯一可以考虑保留 gocode 的情况：除非你是在维护一个非常古老的遗留系统（使用旧的 GOPATH 模式且 Go 版本极低），并且你的开发机器配置极低，对内存占用极其敏感，才需要勉强继续使用 gocode。