fiber中app.put用于全量替换资源，app.patch用于局部更新；需避免空字段覆盖原值，推荐先查原记录再合并非空字段，gorm应显式指定更新列而非save全量更新。
如何用 app.Put 或 app.Patch 处理数据更新请求
Fiber 默认不区分语义严格的 REST 动词行为，app.Put 和 app.Patch 都只是注册路由，真正是否“更新”取决于你写什么逻辑。多数真实项目用 app.Patch 做部分更新（如只改用户名），app.Put 做全量替换（如整个用户对象重置）。
常见错误是直接解包 JSON 后无条件覆盖字段，导致空字符串或缺失字段把原值清掉。比如前端没传 email，后端却用 map[string]interface{} 全量赋值，结果数据库里邮箱变空。
- 用结构体绑定时加
omitempty标签控制字段忽略，但注意这仅影响序列化，不影响反序列化时的零值写入 - 更安全的做法是先查出原记录，再用
mapstructure.Decode或手动赋值方式合并非空字段 - 如果用 GORM，别直接
db.Save(&u)—— 它会更新所有字段；改用db.Select("name", "age").Updates(&u)显式指定要改的列
为什么 c.Params("id") 拿不到 ID 或解析失败
路径参数必须在路由定义里显式声明，比如 app.Patch("/users/:id", handler)。如果写成 /users?id=123，那得用 c.Query("id")，不是 c.Params。
另一个高频坑：ID 是字符串，但数据库主键是 uint，直接 strconv.Atoi(c.Params("id")) 会 panic。Fiber 提供了 c.ParamsInt，它内部做了错误处理并返回 (int, error)，推荐优先使用。
-
c.Params("id")返回原始字符串，适合 UUID、自定义编码等场景 -
c.ParamsInt("id")自动转 int 并捕获转换失败，适合整型主键 - 若 ID 来自 JWT 或中间件注入，别重复从 URL 解析，应从
c.Locals取
GORM 更新时怎么避免 N+1 或漏掉关联字段
用 Preload 加载关联数据后再更新，不是必须的，但如果你要基于关联状态做判断（比如“只有管理员能改冻结状态”），就必须先查出来。否则只靠 ID 更新，会丢失权限上下文。
典型错误是更新主表后，忘记同步更新关联表。例如用户有多个地址，改了用户姓名，但地址表里的 user_name 字段还留着旧值——这不是 GORM 的问题，是你没设计好业务逻辑边界。
- 用
db.Preload("Addresses").First(&user, id)一次查出主 + 关联 - 批量更新关联字段时，别用循环
db.Save()，改用db.Model(&Address{}).Where("user_id = ?", id).Updates(map[string]interface{}{"updated_at": time.Now()}) - 硬编码字段名易出错，建议用 struct tag 如
gorm:"column:user_name"统一管理映射
并发更新时数据被覆盖怎么办
Fiber 本身不提供乐观锁或行级锁封装，得靠你自己加。最轻量的是用数据库的 WHERE version = ? 条件更新，配合 GORM 的 Version 字段自动处理。
另一种常见做法是在更新前先 SELECT ... FOR UPDATE，但注意 Fiber 的默认 DB 连接池是共享的，FOR UPDATE 会阻塞其他 goroutine，高并发下容易卡住。不如用 Redis 做分布式锁，或者直接接受最终一致性（比如订单状态机用幂等 key 控制）。
- GORM 开启
Version字段后，每次更新自动带version = old_version条件，失败时返回RowsAffected == 0 - 别在 HTTP handler 里开事务然后 sleep 模拟耗时操作——这会死锁连接池
- 如果更新逻辑复杂且涉及多个服务，优先考虑发消息异步更新，而不是强一致同步调用
