必须先初始化模块并配置代理：运行go mod init 生成go.mod，再执行go mod edit -require github.com/gin-gonic/gin@latest，同时设置goproxy=https://goproxy.cn,direct和go111module=on。
能跑，但必须先解决依赖和模块路径问题——不是 VSCode 不行，而是 go run 在当前目录找不到包或没初始化 module。
为什么 go run main.go 报错 cannot find package "github.com/gin-gonic/gin"
这不是 VSCode 的锅，是 Go 工具链在当前工作目录下查不到已安装的第三方包。根本原因是：go run main.go 不会自动加载 go.mod 里的依赖，除非你明确告诉它“这是个 module”。
- 你没运行过
go mod init，项目没有go.mod文件 → Go 默认按 GOPATH 模式查找包，而现代 Go（1.16+）默认关闭 GOPATH 模式 - 你运行命令的路径不是 module 根目录（即不含
go.mod的文件夹），go run就不会读取依赖列表 - 即使装了
gin，如果没在go.mod中声明，go run也不会去go/pkg/mod里拉取它
go run . 和 go run main.go 的行为差异
关键区别在于作用域识别方式：前者以当前目录为 module 根，自动扫描所有 .go 文件并解析 import；后者只编译单文件，不触发 module 加载逻辑。
-
go run .：要求当前目录有go.mod，且该文件里已记录github.com/gin-gonic/gin（通过go get或首次构建时自动写入） -
go run main.go：只编译这个文件，不读go.mod，也不检查依赖是否就绪 → 即使go.mod存在也报cannot find package - 多文件项目必须用
go run .，否则go run main.go会忽略同目录下的handler.go、router.go等
VSCode 终端里执行前要确认的三件事
别急着点右键「Run Code」，先看终端当前路径和环境状态：
- 运行
pwd（macOS/Linux）或cd（Windows），确认你在go.mod所在目录 —— 不是某个子文件夹，也不是桌面根目录 - 运行
go list -m all | grep gin（替换gin为你用的包名），确认依赖已出现在 module 列表中；如果没有，说明go get没生效或代理没配好 - 检查
go env GOPROXY输出是否包含有效镜像（如https://goproxy.cn），否则go get github.com/gin-gonic/gin会卡住或失败
调试时提示 dlv: command not found 怎么办
VSCode 的 Go 扩展调试功能依赖 dlv，但它不随 Go 安装，也不由插件自动装全——尤其当你手动 go get 过旧版 dlv，可能和当前 Go 版本不兼容。
- 用
go install github.com/go-delve/delve/cmd/dlv@latest装最新版（Go 1.21+ 推荐），装完运行dlv version看输出 - 如果
dlv装在非默认位置（比如自定义GOPATH），VSCode 可能找不到，需在设置里加"go.delvePath": "/path/to/dlv" - 调试配置里若写了
"program": "${workspaceFolder}/main.go"，但项目实际是cmd/app/main.go，就会找不到入口 → 改成"program": "${workspaceFolder}/cmd/app"更稳妥
最容易被忽略的是：改完 go.mod 后没重新运行 go run .，VSCode 缓存了旧的 build 结果；或者把 main.go 放在 internal/ 目录下——Go 规定 main 包必须在 module 根或显式指定路径，不能藏在 internal 里。
