GoLand提示失效需检查GOROOT和Go Proxy配置，VS Code中gopls失败常见于版本不兼容、缺少go.mod、GO111MODULE=off或vendor未启用；自定义类型无提示多因未保存、跨module或索引未触发。
GoLand 里 go.mod 正确但 still 没提示？检查 go 工具链绑定
GoLand 默认不会自动识别系统 PATH 里的 go，尤其当你用 asdf、gvm 或自定义路径安装时，IDE 可能仍在用旧版本或空工具链。打开 Settings → Go → GOROOT，确认指向的是你当前终端执行 which go 返回的路径；再检查 Go Modules → Go Proxy 是否配置了可用代理（如 https://goproxy.cn），否则 go list -json 查询依赖元信息会超时，导致符号解析失败。
VS Code 中 gopls 启动失败或卡在 “Initializing”？看日志和版本兼容性
gopls 是 VS Code Go 插件的核心语言服务器，提示失效八成跟它有关。按 Ctrl+Shift+P 输入 Go: Toggle Verbose Logging 开启详细日志，再重启窗口，观察输出里是否出现：failed to load view for ...: no matching packages 或 context deadline exceeded。常见原因包括：
-
gopls版本太新，而你的 Go 版本低于 1.20 —— 降级到v0.13.4（适配 Go 1.19）更稳 - 项目根目录下没有
go.work或go.mod，gopls不知道从哪开始索引 -
GO111MODULE=off被意外启用，强制关闭模块模式，gopls将拒绝服务
临时验证方式：终端进项目根目录，手动运行 gopls -rpc.trace -v check .，看是否报错。
代码在 vendor/ 下没提示？确认 go env -w GOFLAGS="-mod=vendor" 是否干扰
某些老项目依赖 vendor 目录，但现代 gopls 默认忽略它，除非显式启用 vendor 模式。不过别直接设 GOFLAGS —— 这会让所有 go 命令（包括构建、测试）都走 vendor，容易引发 CI 不一致。正确做法是：
立即学习“go语言免费学习笔记（深入）”；
- 在项目根目录创建
.gopls配置文件 - 写入：
{ "build.experimentalWorkspaceModule": true, "build.vendor": true } - 重启 VS Code 或重载窗口（
Ctrl+Shift+P → Developer: Reload Window）
注意："build.vendor": true 仅影响 gopls 的符号解析逻辑，不改变 go build 行为。
自定义类型或方法补全缺失？检查是否跨 module 或未触发索引
比如你在 internal/pkg/util 定义了一个 Stringer 接口，但在 cmd/app/main.go 里调用时没提示。这通常不是插件问题，而是 gopls 尚未完成该 package 的类型索引。可尝试：
- 在
main.go顶部加一行空白 import：_ "your-module/internal/pkg/util"，保存后触发重新分析 - 确认
util所在目录有go.mod（哪怕只是空文件），否则gopls视为非模块路径，跳过索引 - 如果类型定义在
example.com/repo/internal，而调用方在example.com/repo/cmd，确保两者属于同一 module（即共用一个顶层go.mod），否则跨 module 导入需显式require
最隐蔽的坑是：你改了类型定义但没保存文件，gopls 缓存的还是旧 AST —— 保存后再等 2 秒，提示往往就出来了。
