应选用 gin.new() 而非 gin.default()，因其可避免默认 logger 的 i/o 瓶颈和 recovery 缺失 trace_id 导致的线上排查困难，并支持按需定制日志与错误上报策略。
为什么不用 gin.Default() 而选 gin.New()
做问卷后台时，你很快会遇到并发导出、大文件上传、敏感字段脱敏、审计日志等需求。用 gin.Default() 会默认加载 Logger 和 Recovery，看似省事，但实际埋了两个坑：Logger 在高并发导出报表时会成为 I/O 瓶颈；Recovery 默认 panic 日志不带 trace ID，线上排查问卷提交失败问题时根本定位不到是哪个 AnswerSheet 解析出的错。
推荐写法：
router := gin.New()
router.Use(gin.Recovery())
if gin.Mode() == gin.DebugMode {
router.Use(customLogger()) // 自定义 logger，只打关键字段，加 trace_id
} else {
router.Use(sentryRecovery()) // 上报 panic 到 Sentry，带上下文
}
- 自定义
customLogger()只记录 method、path、status、latency、trace_id，跳过 body 和 query（问卷参数可能含敏感信息） -
sentryRecovery()需在 panic 前从c.MustGet("trace_id")拿到唯一标识，否则无法关联请求链路 - 别在中间件里解析
c.Request.Body多次——Gin 的 body 只能读一次，问卷 POST 的 JSON 容易因此卡住
问卷数据绑定：用 c.ShouldBindJSON() 还是 c.BindJSON()
问卷提交接口必须容忍部分字段缺失或类型错误（比如用户没填“其他说明”文本框，或把数字题填成字符串），否则一个错就让整份问卷提交失败，体验极差。
c.BindJSON() 遇到字段类型不匹配或必填字段为空，直接返回 400 错误；而 c.ShouldBindJSON() 允许你手动校验并返回更友好的提示，比如“第5题为单选题，请勿填写多个选项”。
实操建议：
- 定义问卷结构体时，所有非强制字段用指针类型，如
Score *int `json:"score"`，避免零值覆盖原始空状态 - 对多选题、矩阵题这类嵌套结构，用
json.RawMessage延迟解析，防止结构体提前解包失败 - 绑定后立刻调用自定义校验函数，检查逻辑约束（如“若选择‘否’，则后续3题不可填”），而不是依赖 struct tag 的
binding:"required"
路由分组要按「问卷生命周期」切，不是按「CRUD」切
问卷后台最常犯的错，是把所有接口塞进 /api/v1/questionnaire 下：创建、发布、回收、导出、删除全混在一起。结果权限配置混乱，发布问卷的运营人员意外删了历史数据，或者导出接口被没权限的人调用导致数据库慢查询拖垮服务。
在 Go 中使用 google/wire 实现编译时依赖注入——wire.NewSet、wire.Build、wire.Bind（接口→实现）、wire.Struct、wire.Value、wire.Interface
正确分组方式是按动作语义隔离：
v1 := router.Group("/api/v1")
{
q := v1.Group("/questionnaire")
{
q.POST("", createQuestionnaire) // 仅限管理员
q.GET("/:id", getQuestionnaire) // 所有登录用户可查自己发起的
q.PATCH("/:id/publish", publishQ) // 需要 "publish" 权限
q.GET("/:id/responses", listResponses) // 需要 "view_response" 权限
q.POST("/:id/export", exportResponses) // 单独限流，防刷
}
}
-
publishQ中间件必须校验问卷状态是否为draft，禁止重复发布 -
exportResponses必须加rate.Limit(1, time.Hour)，且导出前查该问卷最近 24 小时导出次数，超限直接拒绝 - 所有响应类接口（
listResponses、exportResponses）都应支持start_time/end_time查询参数，避免全表扫描
大问卷提交时的 Body 处理陷阱
一份含 50 题、每题最多 10 个选项、附带图片 base64 的问卷，POST body 轻松破 2MB。Gin 默认限制 4MB，看似够用，但有两个隐藏雷：
-
c.Request.Body是io.ReadCloser，如果中间件（比如鉴权）提前读了一次又没重置，后续ShouldBindJSON()就收不到数据 - base64 图片不经过处理直接存 DB，会导致 MySQL
max_allowed_packet报错，或 PostgreSQL 的bytea字段溢出 - Gin 的
MaxMultipartMemory默认 32MB，但上传图片时若没显式设置router.MaxMultipartMemory = 64 ，大问卷里的附件会直接 400
建议做法：
在入口中间件统一处理：c.Request.Body = http.MaxBytesReader(c.Writer, c.Request.Body, 8（限 8MB），再用 <code>io.MultiReader 包装 body 供多次读取；图片字段提取后转存对象存储，DB 只存 URL 和 hash。
复杂点在于：问卷编辑态和提交态的字段结构不同，前端传的可能是带草稿标记的混合结构，后端不做 schema 分离就容易 bind 错。这个边界必须在 controller 层就拆开，不能指望 ORM 或中间件兜底。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
