gin无需安装，关键在于模块初始化、代理配置及default()与new()选择：需在项目根目录执行go mod init，配置goproxy=https://goproxy.cn,direct，开发用gin.new()+logger，生产用gin.default()。
Gin 框架本身没有“安装”这一步——它只是 Go 模块依赖，go get 下载的是代码，不是系统级安装包；真正关键的是模块初始化、代理配置和 gin.Default() 与 gin.New() 的选择差异。
go mod init 必须在项目根目录执行
很多初学者在任意路径下直接 go get github.com/gin-gonic/gin，结果发现 go.mod 没生成，或依赖写进了错误模块。Gin 不会自动创建模块，必须先有 go.mod，否则 import 会报错 no required module provides package github.com/gin-gonic/gin。
- 进项目文件夹后再运行
go mod init myapp（模块名建议用实际路径或仓库名，比如github.com/you/myapp） - 如果已进错目录，删掉残留的
go.mod和go.sum，回到正确路径重来 -
go mod tidy比go get更可靠：它按import自动补全依赖，还能清理未使用的项
国内环境必须配 GOPROXY 才能拉下 gin
直接运行 go get -u github.com/gin-gonic/gin 在国内大概率卡住或报错 timeout 或 connection refused，因为默认代理 proxy.golang.org 不可达。
- 临时生效（推荐首次使用）：
export GOPROXY=https://goproxy.cn,direct（Mac/Linux）或$env:GOPROXY="https://goproxy.cn,direct"（PowerShell） - 永久生效：写入 shell 配置（
~/.zshrc或~/.bash_profile），然后source一下 - 别用
direct单独——它会退回到直连，依然失败；https://goproxy.cn,direct表示“优先走镜像，失败再直连”，更稳妥
gin.Default() 和 gin.New() 的行为差异直接影响调试体验
新手常把 gin.Default() 当成“标准启动方式”，但它自带日志中间件和 Recovery 中间件，掩盖了 panic 错误细节；而 gin.New() 是裸引擎，出错直接崩溃，反而利于定位问题。
- 开发阶段建议用
gin.New()+ 手动加gin.Logger()：r.Use(gin.Logger())，这样日志可读性强，且 panic 不被 recover 掉 - 生产环境才用
gin.Default()，它等价于gin.New().Use(gin.Logger(), gin.Recovery()) - 如果用了
gin.Default()却收不到请求，检查是否忘了r.Run()后面没加端口——默认是:8080，但显式写成r.Run(":8080")更安全
router.GET() 的 handler 函数里别直接 panic
Gin 的 Recovery 中间件只捕获 handler 内部 panic，但如果你在 handler 外部（比如全局变量初始化、init 函数）panic，服务根本起不来，错误信息还藏在 go run 的启动阶段，容易误判为 Gin 问题。
- 所有可能出错的逻辑（如数据库连接、配置加载）尽量放在
main()开头，早暴露问题 - handler 内部用
c.Error()记录错误，而不是panic()；需要中断流程时用c.AbortWithStatusJSON() - 调试时加一句
fmt.Printf("handler start: %s\n", c.Request.URL.Path)，确认路由是否真被命中——有时是路径大小写或斜杠结尾不一致导致 404
最常被跳过的其实是 go mod init 的位置和 GOPROXY 的逗号分隔写法；这两个点卡住，后面所有代码都跑不起来，而不是 Gin 本身有问题。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
