ctx.Query 无法区分参数缺失与空值，因二者均返回空字符串；应优先用 QueryArgs().Has() 判断存在性，再取值；GORM 条件链推荐用指针字段+Scopes 封装，分页需确保 count 与 list 查询条件一致。
为什么 ctx.Query 不能直接处理空字符串和缺失参数
因为 Fiber 的 ctx.Query 对缺失的 query 参数返回空字符串，而不是 nil，这导致你无法区分“用户没传该参数”和“用户传了空值”。比如 /search?name=&age=25 和 /search?age=25 在业务上通常含义不同，但用 ctx.Query("name") 都得到 ""。
实操建议：
- 改用
ctx.QueryParam—— 它在参数完全不存在时返回空字符串，在参数存在但为空（如?name=）时也返回空字符串，仍不够区分；更稳妥的是用ctx.Request().URI().QueryArgs()手动检查键是否存在 - 若需严格语义，先调用
ctx.Request().URI().QueryArgs().Has("name")判断字段是否被显式传递，再取值 - 对布尔型条件（如
?active=true），别用ctx.QueryBool直接 fallback，它遇到缺失或非法值会返回false，掩盖真实意图；应先Has("active")再解析
如何构建可组合的 GORM 条件链
直接拼 SQL 或用 map[string]interface{} 传给 Where 会丢失类型安全、忽略零值判断（比如 0 是合法年龄，但 0 作为 int 默认值容易被误判为“未提供”）。
实操建议：
- 定义搜索结构体，每个字段加指针类型（如
*string,*int），这样nil明确表示“未提供”，*v表示“提供且非空” - 用
gorm.DB.Scopes()封装条件逻辑，例如：func WithName(db *gorm.DB, name *string) *gorm.DB { if name != nil && *name != "" { return db.Where("name LIKE ?", "%"+*name+"%") } return db } - 避免在循环中反复调用
Where——GORM 的链式调用是 lazy 的，没问题；但注意OR条件需用Group包裹，否则优先级出错
前端传参格式与后端解析不一致的典型坑
常见错误现象：前端发 ?tags=go&tags=rust（数组），后端用 ctx.Query("tags") 只拿到第一个值 "go"；或者发 ?filters={"status":"active"}，但没做 URL decode 或 JSON 解析。
实操建议：
- 多值参数统一用
ctx.QueryArray("tags")，它返回[]string，自动处理重复 key - 复杂嵌套条件（如范围查询、多字段 or）建议走
POST /search+ JSON body，用ctx.BodyParser(&searchReq)解析结构体，比 query 更清晰可控 - 如果坚持用 GET，对 JSON-like query（如
?q={"name":{"like":"a"}})），需手动url.QueryEscape前端编码，并在后端用json.Unmarshal解析，别依赖 Fiber 自动转换
分页 + 条件搜索时 count 查询被忽略
很多人只写 db.Find(&results) 拿数据，却忘了分页必须知道总条数来算页码。而 GORM 的 Count 不继承 Where 链上的 scope，尤其用了 Scopes 或自定义 Joins 后，count 和 list 的 SQL 可能不一致。
实操建议：
- 用
db.Session(&gorm.Session{NewDB: true}).Model(&User{}).Where(...).Count(&total)确保复用同一查询条件 - 对带
Joins的 count，GORM 默认会去掉 JOIN 表字段，但可能因 GROUP BY 或 DISTINCT 导致结果不准；此时应显式写db.Table("users").Select("COUNT(*)").Joins(...).Where(...).Scan(&total) - 不要在分页中间件里硬编码
limit/offset，而是用db.Scopes(paginate.Page(page, pageSize))这类封装，把 count 和 data 查询逻辑收拢
Count 行为在复杂查询下并不透明，得靠实际 SQL 日志验证是否真的一致。 
