gin.default() 适合开发，因默认启用 logger 和 recovery 中间件，便于调试请求路径、参数解析及 panic 堆栈；gin.new() 为空白引擎，需手动添加中间件，适用于生产环境自定义可观测性与错误处理。
为什么用 gin.Default() 而不是 gin.New()？
直接上手写路由时，很多人会下意识调用 gin.New()，结果发现日志不输出、静态文件 404、甚至 CORS 都没生效——这不是 bug，是 Gin 的中间件默认不启用。 gin.Default() 内置了 Logger 和 Recovery，对开发阶段排查请求路径、参数解析失败、panic 堆栈至关重要。
如果选 gin.New()，你得手动加：
router := gin.New() router.Use(gin.Logger(), gin.Recovery())
但除非你在做极简嵌入式服务或定制中间件链，否则没必要绕开 gin.Default()。它不重、不慢，也不会污染逻辑。
如何安全地解析 JSON 请求体中的 id 字段？
待办事项 API 里，GET /todos/:id 和 DELETE /todos/:id 看似简单，但实际常把 URL path 参数和 JSON body 里的 id 混用，导致更新/删除错对象。
-
:id必须从 URL 路径提取，用c.Param("id")，别试图从 JSON body 里读 - 若 POST/PUT 请求体含
{"id": "123", "title": "xxx"}，这个id应忽略或校验是否与 URL 中一致 - Gin 默认用
json.Unmarshal，对空字符串、非数字字符串转int会静默失败（返回 0），建议统一用string作 ID 类型，或加binding:"required,numeric"
示例校验：
type TodoUpdate struct {
Title string `json:"title" binding:"required"`
}
// 不要放 ID 字段在这里 —— ID 来自 URL
内存版存储为什么不能直接用 map[int]*Todo？
初学者常这么写：var todos = make(map[int]*Todo)，然后在 handler 里直接读写。问题立刻暴露：并发请求下出现 fatal error: concurrent map read and map write。
Gin 的每个请求都在独立 goroutine 运行，而 Go 原生 map 非并发安全。解决方式只有两种：
- 加
sync.RWMutex，读用RLock()，写用Lock() - 改用
sync.Map（但注意它不支持遍历，且 key 必须是interface{}，类型断言成本略高）
更务实的做法：先用 sync.Mutex 包一层简单结构体，比过早引入 Redis 或数据库更利于快速验证 API 逻辑：
type TodoStore struct {
mu sync.RWMutex
items map[string]*Todo
}
为什么 c.JSON(200, ...) 有时返回空响应？
常见于结构体字段未导出（小写开头），比如：
type Todo struct {
id string `json:"id"` // ❌ 小写 id 不会被 json.Marshal 导出
Title string `json:"title"`
}
Gin 的 c.JSON 底层调用 json.Marshal，遵循 Go 的导出规则：只有首字母大写的字段才参与序列化。结果就是返回 {} 或部分字段丢失。
检查点：
- 所有需 JSON 输出的字段必须首字母大写
- 若字段名想保持小写（如
"created_at"），用 tag 显式声明：CreatedAt time.Time `json:"created_at"` - 避免用
map[string]interface{}临时拼数据——易错、难维护、无类型约束
真正容易被忽略的是：哪怕你写了正确的 struct，如果传给 c.JSON 的是 nil 指针或未初始化的 slice，也会返回空数组或空对象，而不是报错。务必在 return 前打日志或用 fmt.Printf("%+v", v) 确认值存在。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
