Cursor不是Golang开发必需品，VS Code+官方Go插件才是最稳组合；必须点“Install”而非“Skip”安装gopls、goimports、dlv，项目根目录需有go.mod，且启用formatOnSave和go.formatTool为goimports。
Cursor 不是 Golang 开发的必需品，甚至不是推荐起点——它对 go.mod 结构、gopls 语言服务器兼容性差，容易导致跳转失效、补全错乱，新手踩坑率极高。
VS Code + 官方 Go 插件：至今最稳的“开箱即用”组合
绝大多数人装完 Go 和 VS Code 后写的第一个 fmt.Println 不高亮、不补全，根本原因不是环境没配好，而是插件弹出的 “Install all tools” 被点了 “Skip”。这一跳过，gopls、goimports、dlv 全部不会装，IDE 功能直接残废。
必须做的三件事：
- 第一次打开
.go文件时，点 “Install” 而非 “Skip” - 确认设置里启用了
"editor.formatOnSave": true和"go.formatTool": "goimports" - 项目根目录必须有
go.mod（哪怕只是go mod init example.com/foo），否则gopls补全和跳转会大面积失灵
delve 调试：别用 dlv debug 直接跑，环境和编译参数全丢
本地调试时发现环境变量读不到、-ldflags 注入的版本号为空？那是因为 dlv debug 默认不加载 .env，也不透传 go run 那套构建参数。
立即学习“go语言免费学习笔记（深入）”；
正确姿势：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 带环境文件启动：
dlv debug --env-file=.env - 注入编译信息：
dlv debug --build-flags="-ldflags='-X main.Version=abc123 -X main.BuildTime=20260512'" - 远程调试（比如容器内）不要
dlv attach，先在目标端起：dlv dap --headless --listen=:2345 --api-version=2，再配 VS Code 的launch.json连过去
go mod + go vet + gopls：三人组缺一不可
go mod 不只是下载依赖，它是构建可重现性的底线。但很多人忽略一个危险操作：手动删 go.sum 里的某行，再 go mod tidy，旧包可能被静默升级，go mod verify 却不报错。
go vet 是防低级错误的硬门槛，它能揪出：if err != nil { return } 后面跟着 defer f.Close() 这种必然泄漏的写法。
gopls 才是 VS Code 里所有智能功能的后台主力——但它极度依赖 go.mod 正确存在。多模块项目用 go.work 的，必须确保每个子模块都有自己的 go.mod，且 go.work 里 use 路径写对，否则补全/重命名直接失效。
别碰 gofmt 单独用，goimports 才是真实工作流
gofmt 只格式化，不管理导入；goimports 自动增删 import、按字母排序、合并分组，还能识别标准库 vs 第三方包。VS Code 的 Go 插件默认就走 goimports，改配置项 "go.formatTool" 就行。
如果你还在手写 import 或靠 Ctrl+Space 猜包名，说明 gopls 没跑起来，或者项目压根没 go mod init ——这两者比选什么编辑器更关键。
工具链真正的复杂点不在安装，而在各组件之间的隐式耦合：gopls 依赖 go.mod 结构，dlv 依赖构建上下文，go vet 依赖源码解析完整性。任何一个环节断掉，表现出来的症状都像是“功能坏了”，但实际是链条松了——得顺着依赖关系一节节查，而不是换新工具。
