不能直接用 gin.default() 上线，因其默认启用 logger（泄露 token/密码等明文信息）和 recovery（返回含源码路径的错误页），且监听 0.0.0.0:8080 暴露内网端口；生产环境须用 gin.new() + 自定义中间件 + 显式绑定地址。
直接用 gin.Default() 启动服务是最简路径，但生产环境必须替换掉默认中间件、禁用调试日志、显式绑定端口——否则会暴露敏感信息或被拒绝服务攻击打垮。
为什么不能直接用 gin.Default() 上线
gin.Default() 自动注入 Logger 和 Recovery 中间件，这对开发友好，但有三个硬伤：
-
Logger输出完整请求头、参数、堆栈，日志文件里全是明文 token 和密码 -
Recovery在 panic 时返回详细错误页面（含源码路径、变量值），攻击者可借此探测内部结构 - 默认监听
0.0.0.0:8080，没做端口/地址约束，容器或云环境可能意外暴露内网端口
gin.New() + 手动注册中间件的最小安全组合
生产启动必须从 gin.New() 开始，只加真正需要的中间件：
- 用
gin.LoggerWithWriter()替代默认 logger，把日志重定向到文件或io.Discard - 用自定义
RecoveryWithWriter()捕获 panic，只返回500 Internal Server Error，不带任何上下文 - 显式调用
r.Run("127.0.0.1:8080")，避免绑定到全网接口
示例片段：
r := gin.New()
r.Use(gin.LoggerWithWriter(&lumberjack.Logger{
Filename: "logs/access.log",
MaxSize: 100,
}))
r.Use(gin.RecoveryWithWriter(&lumberjack.Logger{
Filename: "logs/error.log",
MaxSize: 100,
}))
r.GET("/ping", func(c *gin.Context) {
c.JSON(200, gin.H{"message": "pong"})
})
r.Run("127.0.0.1:8080")
路由参数获取：别混用 c.Query()、c.Param() 和 c.GetHeader()
三种参数来源对应不同 HTTP 位置，拿错就收不到值：
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
-
c.Query("key")只读 URL 查询参数，如/user?id=123中的id -
c.Param("id")只读路径占位符，如r.GET("/user/:id")中的:id -
c.GetHeader("Authorization")只读请求头，JWT token 必须走这里，不能塞进 query
常见错误：把 token 放 query 里传，导致日志泄露、CDN 缓存、代理记录——所有中间件都可能看到它。
JSON 绑定失败时，c.ShouldBindJSON() 不会自动返回 400
很多人以为 c.ShouldBindJSON(&v) 失败会中断执行并返回错误，实际它只返回 error，后续代码照常运行。必须手动检查：
- 漏判
err != nil→ 空结构体入库、panic 或静默失败 - 用
c.BindJSON()更危险：出错直接 400，但不告诉你哪条字段错了，前端无法精准修复 - 推荐组合：
if err := c.ShouldBindJSON(&u); err != nil { c.JSON(400, gin.H{"error": "invalid json"}) }
结构体字段标签要写全：type User struct { Name string `json:"name" binding:"required"` }，否则 binding 不生效。
最易被忽略的是中间件顺序：注册顺序 = 执行顺序。比如想先鉴权再打日志，就得把 auth 中间件写在 logger 前面；反过来，日志里就看不到认证结果。这个顺序一旦写错，排查成本远高于写错一行路由。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
