beego ORM 更新单条记录必须先 Read 再 Update，否则未加载字段按零值处理可能误清空或失败；正确流程是：构造带主键对象→Read 加载数据→修改字段→Update 提交，且推荐显式指定字段名避免覆盖。
beego ORM 更新单条记录必须先 Read 再 Update
直接传入部分字段的结构体调用 Update 会失败或静默忽略 —— 因为 beego ORM 的 Update 默认只更新**已加载到内存且非零值**的字段，而主键以外的字段若未从数据库读出，其值是零值（比如 int 是 0、string 是 ""），ORM 会跳过这些字段，甚至可能把非空字段误清空。
正确流程是三步：构造带主键的对象 → Read 加载完整数据 → 修改字段 → Update 提交。
- 如果只传
Id，o.Read(&user)会按主键查；若想按其他字段查（如Name），需显式指定：o.Read(&user, "Name") -
Read失败时返回orm.ErrNoRows或orm.ErrMissPK，不检查就直接Update会导致 panic 或写入错误行 - 结构体字段 tag 中必须有
pk（主键）标识，否则Read和Update无法定位记录
Update 只更新部分字段要显式传字段名
默认调用 o.Update(&user) 会尝试更新所有非主键字段（除 auto 字段外），容易覆盖你不希望修改的字段（比如 Created 时间戳被重置）。生产环境务必限制更新范围。
- 只更新
Name和PassWorld：o.Update(&user, "Name", "PassWorld") - 字段名必须和 struct tag 中
column值一致（如orm:"column(pass_world)"，则传"pass_world"） - 不能传 struct 字段名（如
"PassWorld"），除非 tag 明确未指定column，否则会报field not found - 传空字段名列表（
o.Update(&user)）等价于更新全部可写字段，高风险操作
Raw SQL 更新更可控，但绕过 ORM 验证
当需要条件复杂（如 WHERE status = ? AND updated_at ）、或批量更新、或避免两次查询时，Raw + Exec 是更直接的选择。它不依赖模型加载，也不触发钩子（PreUpdate 等）。
- 语法：
o.Raw("UPDATE user SET name = ?, pass_world = ? WHERE id = ?", newName, newPass, id).Exec() - 返回
sql.Result，可用RowsAffected()判断是否真有记录被改 - 注意参数顺序必须与
?占位符严格对应，错一位就会更新错字段或报错 - 不校验字段是否存在、类型是否匹配，SQL 写错只能靠日志或数据库报错反馈（如
Error 1054: Unknown column）
Update 返回值不是 ID，而是影响行数
新手常误以为 Update 和 Insert 一样返回自增 ID，实际上它返回的是 int64 类型的受影响行数，且仅当 > 0 才代表成功更新了数据。
- 正确用法：
rows, err := o.Update(&user, "Name"); if err != nil || rows == 0 { /* 处理失败 */ } - 如果
rows == 0，可能是主键不存在、WHERE 条件不匹配，或字段值未变（MySQL 的sql_mode=STRICT_TRANS_TABLES下可能不报错但返回 0） - 别依赖
err == nil就认为数据已变 —— ORM 不保证“值不同才更新”，它只管 SQL 执行结果
实际更新逻辑里最容易被忽略的，是字段零值与数据库默认值的冲突。比如一个 int 字段数据库允许 NULL，但 Go struct 中没加指针，Read 后设为 0 再 Update，就会把原本的 NULL 覆盖成 0。这种隐式转换必须靠字段类型设计（用 *int）或显式 SQL 控制。
