Gin的router.GET()不生效主因是未调用router.Run()、端口被占、路由注册顺序错误或误用gin.New()；全局中间件用Use()，路由级在GET中传参；JSON校验优先ShouldBindJSON+binding tag；生产环境必须设GIN_MODE=release禁用DebugMode。
为什么 Gin 的 router.GET() 不生效？
常见现象是浏览器访问 /hello 返回 404，但代码里明明写了 router.GET("/hello", ...)。根本原因通常是启动时没调用 router.Run()，或者监听端口被占用、防火墙拦截，又或者路由注册在 router := gin.Default() 之前（比如先写了 handler 再初始化 router）。
- 确保
router.Run(":8080")是 main 函数最后一行可执行语句，且没有 panic 中断它 - 检查是否误用了
gin.New()—— 它默认不启用 logger 和 recovery 中间件，请求日志不输出，容易误判“没跑起来” - 如果用 IDE 调试，确认进程确实在监听端口：
lsof -i :8080（macOS/Linux）或netstat -ano | findstr :8080（Windows）
Gin 中间件怎么区分全局和路由级？
Use() 是全局中间件，所有路由都会走；GET("/path", middleware1, handler) 这种写法才是路由级中间件，只对当前路由生效。混淆这两者会导致鉴权逻辑意外跳过，或日志重复打印。
- 全局中间件适合日志、CORS、JWT 校验（需覆盖全部接口）：
router.Use(gin.Logger(), gin.Recovery(), auth.Middleware()) - 路由级中间件适合特定路径的权限控制，比如管理后台接口：
adminRouter.GET("/users", adminAuth(), userHandler.List) - 注意中间件函数签名必须是
func(*gin.Context)，返回值不能是 error 或 bool —— Gin 不靠返回值判断是否继续，而是靠c.Next()和c.Abort()
如何正确解析 JSON 请求体并校验字段？
直接用 c.BindJSON(&struct{}) 看似简单，但字段缺失、类型错位、空字符串未过滤等问题会在运行时暴露，且错误提示不明确。Gin 默认用 json.Unmarshal，不支持 struct tag 外的校验逻辑。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 优先用
c.ShouldBindJSON()替代BindJSON()，它不自动中止请求，允许你统一处理错误：if err := c.ShouldBindJSON(&req); err != nil { c.JSON(400, gin.H{"error": "invalid input"}) } - 结构体字段加
binding:"required"tag 做基础非空校验，但注意：数字类型零值（如int的 0）不会触发 required 报错，需额外判断 - 避免在 handler 里手动
json.Unmarshal(c.Request.Body)—— Gin 的Bind系列方法会重置 body reader，重复读会失败
为什么生产环境要禁用 gin.DebugMode？
开启 Debug 模式（默认行为）会暴露详细错误堆栈、渲染模板时显示文件路径、甚至允许热重载 —— 这些在开发时方便，但上线后等于把内部结构白送攻击者。更隐蔽的问题是：Debug 模式下 gin.Default() 会插入 gin.Logger()，而该中间件在高并发下有性能损耗（尤其写磁盘日志时）。
立即学习“go语言免费学习笔记（深入）”；
- 强制关闭方式：
gin.SetMode(gin.ReleaseMode)，必须在gin.Default()或gin.New()之前调用 - 环境变量控制更稳妥：
os.Setenv("GIN_MODE", "release")，放在 main 函数最开头 - 别依赖
.env文件自动加载 —— Gin 不读取 .env，得自己用godotenv类库配合
路由嵌套、中间件顺序、JSON 绑定细节这些地方，改一行代码就可能让整个 API 行为突变，比语法错误更难定位。
