ci4查询构建器不支持链式条件更新，必须显式添加where条件再调用update()，否则会全表更新；推荐使用model类并配置$primarykey和$allowedfields以提升安全性。
CI4 的 Builder 类（即查询构建器）本身不支持“链式条件更新”这种一次性写法——它没有像 Laravel 那样的 updateOrCreate() 或自动合并 where 条件的 update 方法。所谓“链式条件更新”，实际是指用 Query Builder 拼接 where()、orLike() 等条件后，再调用 update()。但这里极易出错，必须明确两点：更新必须带有效 WHERE 条件；不能复用未重置的 builder 实例。
更新前必须指定 WHERE 条件
直接调用 $builder->update($data) 而不加 where()，会更新整张表所有行，且无报错提示。这是 CI4 最隐蔽也最危险的坑之一。
- 正确写法：先用
where()锁定目标记录，再传数据更新 -
错误示例：
$builder->table('users')->update(['status' => 'active'])→ 全表 status 变 active -
正确示例：
$builder->table('users')->where('id', $id)->update(['status' => 'active']) - 多条件可用链式：如
where('status', 'pending')->whereIn('type', ['a','b'])
慎用 orLike/groupStart 等复杂条件
当更新逻辑依赖模糊匹配（如按用户名或邮箱搜出记录再更新），需用 orLike() 或 groupStart()。但这些方法只在当前 builder 实例中生效，一旦调用过 update()，builder 内部状态可能被清空或复用失效。
- 不要这样写：
$builder->orLike('name', $q)->orLike('email', $q)->update($data) - 推荐拆解：先查出 ID 列表，再用
whereIn('id', $ids)安全更新 - 或新建 builder 实例专用于更新：
$db->table('users')->where(...)->update($data)
用 Model 替代裸 builder 更安全
CI4 官方推荐优先使用 Model 类做更新操作，它自动校验主键、白名单和类型，比手动拼 builder 更健壮。
- 模型必须定义
protected $primaryKey = 'id'和protected $allowedFields = ['status'] - 按主键更新：
$model->update($id, ['status' => 'done']) - 按条件更新（不依赖主键）：
$model->builder()->where('status', 'draft')->update(['status' => 'sent']) - 单选字段（如 radio）要先校验值合法性，再转类型：
(int)in_array($val, ['1','2','3']) ? $val : '1'
分页+筛选场景下的更新注意事项
如果更新操作发生在带搜索条件的分页列表页，用户翻页后 POST 数据丢失是常态。此时不能靠翻页链接保留筛选参数。
- 解决方案一：把筛选条件存入 session，在控制器中读取并重新应用到 builder
- 解决方案二：改用 GET 表单提交（配合
current_url(true)生成带参数的分页链接） - 避免混合：不要让 POST 表单提交后跳转到带 page=2 的 URL，否则筛选条件必然中断
