Go插件装了但没补全？检查 gopls 是否真正启用
VSCode 的 Go 插件（golang.go）默认依赖 gopls 提供语义补全、跳转和诊断，但很多人装完插件就以为万事大吉——其实 gopls 很可能根本没跑起来。
常见错误现象：Ctrl+Space 只有基础语法提示，没有字段/方法补全；F12 跳转失败；保存后无 go vet 或 staticcheck 报错。
- 打开命令面板（
Ctrl+Shift+P），运行Go: Install/Update Tools，勾选gopls并安装 - 确认
gopls在终端可执行：which gopls（macOS/Linux）或where gopls（Windows） - 在 VSCode 设置中搜索
go.goplsPath，确保值为空（走默认路径）或指向正确二进制（如/usr/local/go/bin/gopls） - 关闭所有文件夹，重新用 VSCode 打开一个
go.mod所在根目录——gopls只在有模块的 workspace 下激活
调试时提示 “could not launch process: fork/exec … no such file or directory”
这是 dlv（Delve）找不到 Go 二进制或工作目录不对导致的，不是插件配置问题，而是运行时上下文缺失。
使用场景：点击绿色 ▶️ 启动调试、或按 F5 后立刻报错，且错误里带完整路径（如 fork/exec /path/to/main: no such file or directory）。
立即学习“go语言免费学习笔记（深入）”；
- 确保项目根目录下存在
go.mod，且已执行过go mod tidy - 调试前先手动构建一次：
go build -o ./main .，确认能生成可执行文件 - 检查
.vscode/launch.json中的program字段：推荐用"${workspaceFolder}"，而不是硬编码"./main"或相对路径 - Windows 用户注意：如果用 WSL 开发，VSCode 必须是 WSL 版本（底部状态栏显示
WSL: Ubuntu），否则dlv和go环境不匹配
补全卡顿、响应慢？调低 gopls 的内存压力
gopls 默认会索引整个 module 及其依赖，大型项目（尤其含大量 vendor 或 internal 工具链）容易吃光内存、拖慢补全。这不是插件 bug，是设计权衡。
性能影响：输入后等 2–3 秒才出提示；CPU 持续 80%+；VSCode 状态栏一直显示 “Loading packages…”。
- 在 VSCode 设置中搜索
go.goplsArgs，设为：["-rpc.trace", "--debug=localhost:6060"]（仅调试用）或更实用的：["-rpc.trace", "-logfile", "/tmp/gopls.log"] - 限制索引范围：在项目根目录加
gopls.json（或settings.json中配"gopls": { "build.experimentalWorkspaceModule": false }） - 对超大单体项目，临时禁用 vendor 索引：
go.goplsArgs加上"-modfile=go.mod"和"-no-vendor" - 别用
go.work文件管理多模块——gopls对它的支持仍不稳定，易触发重复加载
Mac 上调试断点不命中？检查 dlv 和 Go 版本兼容性
Go 1.21+ 默认开启 buildmode=pie，而旧版 dlv（
错误信息典型特征：could not launch process: unsupported binary format 或控制台输出 exec format error。
- 升级
dlv到最新稳定版：go install github.com/go-delve/delve/cmd/dlv@latest - 验证版本：
dlv version应显示Version: 1.22.0或更高（对应 Go 1.22+ 兼容） - 若仍不行，在
launch.json中显式禁用 PIE："env": {"CGO_ENABLED": "0"}, "args": ["-gcflags", "all=-l"]（仅开发期临时用） - Mac M 系列芯片用户注意：不要混用 Intel 和 ARM64 的 Go SDK，
which go和go version输出的架构必须与dlv一致
最常被忽略的是：改完 gopls 或 dlv 配置后，必须重启 VSCode 窗口（不只是重载窗口），否则新设置不生效。gopls 进程是 workspace 级驻留的，缓存很顽固。
