gin.default()初始化后路由不生效的根本原因是未调用r.run()启动http服务，或端口被占用；engine实例本身不监听，run()才绑定http.listenandserve，默认:8080，冲突时需显式指定端口。
gin.Default() 初始化后为什么路由不生效？
常见现象是代码写了 r.GET("/ping", handler) 却访问 404，根本原因是没调用 r.Run() 或监听端口被占用。Gin 的 Engine 实例本身不启动服务，Run() 才真正绑定 http.ListenAndServe。
-
Run()默认监听:8080，若端口被占会 panic，可显式传参如r.Run(":3000") - 使用
gin.New()而非Default()时，日志和 recover 中间件需手动加：r.Use(gin.Logger(), gin.Recovery()) - Windows 下杀进程常用命令：
netstat -ano | findstr :8080→ 记下 PID →taskkill /PID xxx /F
分组路由 Group 里中间件作用域怎么控制？
Group() 返回的 *RouterGroup 是独立作用域，中间件只对本组内注册的路由生效，不影响父级或兄弟组。但要注意：中间件注册顺序决定执行顺序，且 Group() 支持链式调用传入多个 HandlerFunc。
Alibabacloud Sdk Client Initialization For Golang
下载
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 全局中间件用
r.Use(...)；组级用v1 := r.Group("/v1", authMiddleware) - 组内嵌套组也遵循作用域隔离，比如
v1.Group("/admin").Use(adminOnly)不影响v1.Group("/user") - 中间件函数必须接收
*gin.Context并调用c.Next()才能继续后续处理链
Context 复用机制导致哪些隐藏问题？
Gin 用 sync.Pool 复用 gin.Context 实例，性能好但容易误用：一旦在 goroutine 中异步保存 c 或其字段（如 c.Request、c.Writer），可能引发数据错乱或 panic，因为该 Context 可能在其他请求中被重置。
- 禁止在 goroutine 里直接捕获
c，应提取必要字段如userID := c.GetString("user_id") -
c.Copy()可安全复制一份上下文用于异步操作，但注意它不复制Writer状态 - 不要把
c.Request.Body直接传给后台任务——Body 是 io.ReadCloser，已被 Gin 读过一次，再次读会返回空
JSON 渲染时 struct tag 写错导致字段丢失
c.JSON(200, obj) 返回空对象或字段名不对，90% 是 struct 字段未导出（小写开头）或 JSON tag 拼写错误。Go 的 json 包只序列化导出字段，且 tag 值必须用双引号包裹。
- 错误写法：
Name string `json:name`（缺双引号）→ 字段被忽略 - 正确写法：
Name string `json:"name"`或Name string `json:"name,omitempty"` - 嵌套结构体字段也要导出，否则整个嵌套对象为空：
Profile Profile `json:"profile"`中Profile的字段也得大写开头
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
