gin_mode=debug必须显式在launch.json的env中设置，否则gin以release模式运行导致断点跳过；断点只能设在handler函数内部（如handleuser），不能设在main()末尾或router.run()后，因程序此后阻塞于http循环。
GIN_MODE=debug 必须显式设置，否则断点不触发
VSCode 启动调试时默认不继承终端环境变量，GIN_MODE 仍为 release，导致 Gin 静默所有日志、路由注册不打印、HTTP 请求也不输出——更关键的是，handler 函数虽被调用，但调试器可能因模式切换丢失上下文，断点看似“命中”实则跳过。这不是 VSCode 或 Delve 的 bug，而是 Gin 在 release 模式下主动屏蔽了调试钩子。
必须在 launch.json 的 env 字段中硬编码指定：
{
"env": {
"GIN_MODE": "debug"
}
}
- 不要依赖 shell 中临时 export，VSCode 调试进程不读取它
- 不要在代码里写
gin.SetMode(gin.ReleaseMode)，哪怕注释掉也要删干净 - 如果项目有
.env文件，确保它没覆盖GIN_MODE（Delve 不自动加载 .env）
断点只能设在 handler 函数内部，不能设在 main() 末尾
Gin 启动后调用 router.Run() 就进入阻塞式 HTTP server 循环，main goroutine 停在那里不再执行后续代码。所以把断点打在 main() 最后一行、或 router.Run() 后面，调试器永远等不到那个“下一行”。
真正有效的断点位置是实际处理请求的函数体里：
func handleUser(c *gin.Context) {
userID := c.Param("id") // ✅ 在这里设断点
user, _ := findUserByID(userID)
c.JSON(200, user)
}
- 断点必须位于
router.GET("/user/:id", handleUser)这类注册的 handler 函数中 - 中间件函数（如
func auth(c *gin.Context)）里也能设断点，只要它被实际调用 - 用
curl http://localhost:8080/user/123或 Postman 触发请求，断点才会激活
launch.json 必须用 mode: auto 或 exec，不能用 test
VSCode Go 插件对不同 mode 的行为差异很大：test 模式会尝试运行 go test，而 Gin 项目入口是 main()，不是测试函数，结果就是调试器启动失败或直接退出。
正确配置只保留两个安全选项：
"mode": "auto", // 推荐：自动识别 main.go 并走 exec 流程 // 或 "mode": "exec"
-
program必须指向具体文件，如${workspaceFolder}/main.go，不能是目录 -
request必须是launch，attach需要先手动启进程，对 Gin 开发太绕 - 如果用了 Go Module，确保
go.mod在 workspace 根目录，否则 Delve 可能找不到依赖
调试时看不到 gin.Context 字段？检查 gopls 和 Delve 版本
VSCode 的变量面板里点开 c（*gin.Context）经常显示 unreadable 或字段为空，不是代码问题，而是调试器与语言服务器协同失效。
根本原因是 gopls（提供类型信息）和 dlv（实际调试）版本不匹配，尤其当你升级 Go 后没同步更新工具链：
- 运行
go install github.com/go-delve/delve/cmd/dlv@latest更新 Delve - 运行
go install golang.org/x/tools/gopls@latest更新 gopls - 重启 VSCode，按
Ctrl+Shift+P输入Go: Install/Update Tools全量校验 - 如果仍无效，在
launch.json加上"dlvLoadConfig": { "followPointers": true, "maxVariableRecurse": 1, "maxArrayValues": 64 }
最常被忽略的一点：Gin 的 *Context 是个带大量未导出字段和接口嵌套的结构，调试器默认不展开深层指针，必须靠 dlvLoadConfig 显式放开限制，否则你看到的只是个空壳。
