gopls配置不生效主因是未被正确加载：优先读workspace根目录gopls.json；go.work启用后忽略单module配置；修改后须手动重启语言服务器；应通过"go.goplsArgs"而非"gopls"对象设参数。
gopls 配置不生效的典型表现
改了 settings.json 或 gopls 的 go.work、go.mod 目录下 gopls 配置，但代码补全还是慢、跳转不准、诊断没反应——大概率不是配置写错了，而是 gopls 没读到你改的那份。
- VS Code 中
gopls默认优先读取 workspace 根目录下的gopls.json（如果存在），而不是用户级设置 - Go 工作区（
go.work）启用后，gopls会忽略单个 module 的go.mod目录配置，只认 work 文件所在路径的配置 - 修改配置后没重启 gopls：VS Code 不会自动 reload 语言服务器，必须手动触发
Developer: Restart Language Server
VS Code 中正确覆盖 gopls 启动参数
很多性能问题（比如大型项目卡顿、索引超时）本质是 gopls 启动时默认参数太保守。直接改 "gopls": { ... } 字段容易被覆盖，真正可控的位置是 "go.toolsEnvVars" 或 "go.goplsArgs"。
-
"go.goplsArgs"是最直接的方式，例如加-rpc.trace调试或-logfile查日志；生产环境常用--skip-unopened-files=true减少内存占用 - 避免在
"gopls"对象里写"build.experimentalWorkspaceModule": true这类字段——它只在 gopls v0.13+ 生效，且 VS Code 的 Go 扩展可能将其忽略 - 若用
go.work，确保"go.goplsArgs"放在 workspace settings（不是 user settings），否则 gopls 启动时找不到对应 work 文件上下文
module 依赖爆炸导致 gopls 卡死的实操缓解
项目里 import 了大量外部 module（尤其是含 cgo 或生成代码的），gopls 会在后台同步解析全部依赖，一卡就是几十秒。这不是 bug，是设计使然——它默认不跳过未打开的文件，也不限制并发解析数。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 在
"go.goplsArgs"加上--skip-unopened-files=true，能立刻降低内存峰值和启动延迟 - 禁用不必要的分析器：
--disable=all再按需开，比如只留composites和shadow，避免fillreturns或unusedparams在大项目里反复扫描 - 检查
go env GOCACHE是否指向 SSD；若在 NFS 或机械盘上，gopls 编译缓存读写会拖垮响应速度
为什么改了 GO111MODULE=on 还不生效
有些老项目靠 export GO111MODULE=on 硬切模块模式，但 gopls 启动时并不继承 shell 环境变量——它由 VS Code 进程派生，只认 "go.toolsEnvVars" 显式传入的值。
立即学习“go语言免费学习笔记（深入）”；
- 必须在 VS Code 设置中配
"go.toolsEnvVars": { "GO111MODULE": "on" }，不能只改终端里的环境变量 - 若项目根目录没有
go.mod，即使设了GO111MODULE=on，gopls 仍以 GOPATH 模式运行，补全和类型推导会错乱 - 多 module 工作区下，
GO111MODULE必须为on，否则go.work文件会被忽略，gopls 回退到单 module 模式
配置生效与否，关键不在“写了什么”，而在“gopls 实际启动时看到的是什么”。每次改完，务必打开命令面板执行 gopls -rpc.trace -v check . 看它实际加载了哪些配置和模块路径。这点最容易被跳过。
