Gin中GET /users/:id返回404的主因是未在handler中调用c.Param("id")获取参数，导致业务逻辑误判为用户不存在；需确保路由注册正确、首行取参、妥善处理类型转换与错误。
查询用户时为什么 GET /users/:id 路由总返回 404？
Gin 默认不自动解析路径参数，必须显式调用 c.Param("id") 才能取到 :id 的值。如果只写了路由但没在 handler 里读取，Gin 不会报错，但业务逻辑里拿不到 ID，容易误判为“查无此用户”而返回 404。
常见错误写法：router.GET("/users/:id", func(c *gin.Context) { /* 忘了 c.Param("id") */ })
- 确保路由注册正确：
router.GET("/users/:id", getUserHandler) - 在 handler 中第一行就取参数：
idStr := c.Param("id")，再做类型转换 - 注意字符串转整型时的错误处理，
strconv.Atoi(idStr)失败要返回c.JSON(400, gin.H{"error": "invalid id"})
用 Query 还是 Param 查询用户更合适？
取决于语义和缓存行为：/users/123（Param）表示资源唯一标识，可被 CDN 或浏览器缓存；/users?id=123（Query）更适合条件组合查询，比如 ?name=xxx&status=active。
- 单个用户详情 → 用
Param：/users/:id，符合 REST 规范，也利于 Gin 路由树匹配性能 - 模糊搜索或分页列表 → 用
Query：c.Query("name")、c.DefaultQuery("page", "1") - 混合使用没问题，但别把主键塞进 Query 里还声称“RESTful”，Gin 不拦你，但下游网关或监控系统可能不认
c.ShouldBindQuery 和手写 c.Query 哪个更安全？
c.ShouldBindQuery 适合结构化查询参数（比如分页 + 状态 + 时间范围），它会自动做类型转换和校验；但对简单单字段查询（如只查一个 id），直接 c.Query 更轻量、意图更明确，也更容易调试。
- 用
ShouldBindQuery时，结构体字段必须带formtag，例如：type UserQuery struct { ID uint `form:"id" binding:"required,gt=0"` } - 若参数非必填，别加
binding:"required"，否则校验失败直接 400；可用binding:"omitempty,gt=0" - 注意：空字符串传给
uint字段会触发校验失败，前端传?id=和不传id在 Gin 里表现不同
数据库查询后，怎么避免 N+1 和空指针 panic？
Gin 本身不处理 ORM 层逻辑，但 handler 里常因疏忽导致两个问题：一是查用户时顺带查订单却没预加载，引发 N+1；二是 db.First(&user, id) 找不到记录时 user 是零值，但直接访问 user.Name 没问题，而 user.Profile.Avatar（关联结构）可能 panic。
- 查单条用户，优先用
db.Preload("Profile").First(&user, id)避免额外 SQL - 总是检查 GORM 错误：
if errors.Is(err, gorm.ErrRecordNotFound) { c.JSON(404, gin.H{"error": "user not found"}); return } - 不要假设结构体字段一定有值，特别是关联字段 —— 可用
if user.Profile != nil判断后再取值
最常被忽略的是错误分类：GORM 的 ErrRecordNotFound 和数据库连接失败、超时等错误必须区分对待，前者是业务正常流，后者得打日志并返回 500。
