gosublime 已停止维护，新老项目均应迁出；其依赖的旧工具与 go 模块模式严重不兼容，导致补全失败、路径错误等问题；推荐改用 lsp+gopls 或 vs code+go 扩展。
GoSublime 已停止维护，新项目别用，老项目也建议尽快迁出。它在 Go 1.11+ 模块模式普及后就和官方工具链严重脱节，不是“怎么用好”的问题，而是“用就会踩坑”。
GoSublime 报错 gocode: command not found 或无法补全
这是最常见现象，本质是 GoSublime 依赖的旧版 gocode、guru、goimports 等工具不兼容现代 Go 工作流。Go 1.16 起默认启用 GO111MODULE=on，而 GoSublime 的构建逻辑仍硬编码 GOPATH 路径，导致它根本找不到你模块里的包。
- 不要手动
go get github.com/nsf/gocode—— 这装的是已废弃的旧版，和gopls冲突 - 不要在
GoSublime.sublime-settings里强行指定"env": {"GOROOT": "...", "GOPATH": "..."}—— Sublime Text 启动方式会让这些环境变量失效 - 真正有效的补全/跳转/格式化，现在只靠
gopls，它不接受 GoSublime 的调度
想在 Sublime Text 里写 Go，该换什么
不是“有没有替代品”，而是“哪些能和当前 Go 官方工具链对齐”。目前只有两个靠谱路径：
-
SublimeLinter + LSP 插件 + gopls：用
LSP插件（不是 GoSublime）连接本地运行的gopls，补全、诊断、hover 全都正常；SublimeLinter负责调用go vet或staticcheck -
直接用 VS Code + Go 扩展：它背后也是
gopls，但配置零成本，go.mod识别、测试运行、竞态检测都开箱即用
注意：LSP 插件需要手动配置 "command": ["gopls"]，且确保 gopls 在 $PATH 中（推荐 go install golang.org/x/tools/gopls@latest）。
还在用 GoSublime？迁移时最易忽略的三件事
很多人以为删掉插件就完事，结果发现测试跑不了、import 排序乱了、甚至 go run main.go 都报 no required module provides package。
-
GO111MODULE环境变量没设对：Sublime Text 从桌面图标启动时，不会继承 shell 的环境变量，必须在LSP.sublime-settings里显式加"env": {"GO111MODULE": "on"} - 旧的
gofmt配置残留：GoSublime 曾强制绑定goreturns，现在得删掉所有"gofmt_command"类设置，改用gopls内置的格式化 -
build系统没更新：Sublime Text 原生Go.sublime-build不支持模块，要改成调用go build -mod=readonly，否则 CI 构建行为会和本地不一致
真正麻烦的从来不是装不上，而是它悄悄绕过 go.mod 解析、缓存错误的符号信息、让 gopls 无法接管——这些问题不会报错，只会让你某天突然发现跳转进了一个不存在的函数签名里。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
