save(false)仅绕过validate()但不跳过数据库约束等其他失败条件；适用于已校验数据的批量修正或迁移，禁用于用户输入；注意软删除、事务、字段类型问题。
save(false) 不是“跳过验证就一定能更新成功”的快捷键，它只是绕开 validate()，但其他失败条件（如数据库约束、字段类型不匹配、软删除条件缺失）依然会拦住你。
什么时候该用 save(false)
你明确知道当前数据已通过其他方式校验（比如前端传入、后台逻辑生成、或已调用过 validate() 且通过），且想省掉重复校验开销；或者你正在做批量属性修正（如统一改 createdby 字段），而模型规则里对这些字段有非空/格式限制，但业务上允许临时绕过。
- 常见场景：后台运营脚本批量修正字段、迁移旧数据、定时任务补全缺失值
- 不适用场景：用户提交表单、API 接口写入、任何未经可信路径预处理的数据
- 注意：
save(false)不影响beforeSave/afterSave事件触发，也不跳过时间戳行为（updatedAt仍会被自动更新）
save(false) 和 update(false) 的关键区别
update(false) 是 ActiveRecord 实例方法，只用于已有记录的 UPDATE 操作；save(false) 是 Model 基类方法，会根据 $model->isNewRecord 自动选 INSERT 或 UPDATE —— 所以它更通用，但也更容易误用。
- 用
update(false)前必须确保模型是从数据库查出来的（比如User::findOne($id)），否则报错 “Trying to update record that does not exist” - 用
save(false)时若模型是 new 出来的，它会走 INSERT 流程，哪怕主键已设 —— 这可能触发唯一索引冲突 - 二者都跳过
validate()，但都不跳过数据库层约束（如 NOT NULL、外键、CHECK）
容易踩的坑：软删除、事务、字段类型
最常被忽略的是软删除条件和字段类型校验。ActiveRecord 默认在 WHERE 条件中加 deleted_at IS NULL，但 save(false) 不会帮你加 —— 如果你没手动查出模型再改再存，而是 new 一个带 id 的模型直接 save(false)，它可能去 UPDATE 一条已被逻辑删除的记录。
- 字段类型不匹配：gii 生成的模型常把
TINYINT字段 rule 设为string，你传整数 1，validate()会挂，但save(false)会直接扔进 SQL，MySQL 可能静默转成 0 或报错 - 事务未包裹：批量用
save(false)时，如果中间某条失败，前面成功的不会自动回滚 —— 必须手动Yii::$app->db->beginTransaction() - 时间戳字段被清空：若模型里没定义
updatedAt行为，又没显式赋值，save(false)后该字段可能变 NULL，而不是自动更新
替代方案：比 save(false) 更安全的批量更新
如果你只是为了改几个字段值，又不想走模型生命周期，DAO 的 update() 或 createCommand()->update() 更轻量、更可控，也天然规避软删除失效问题。
- 推荐写法：
Yii::$app->db->createCommand()->update('user', ['status' => 2], ['id' => $ids])->execute() - 它不加载模型、不触发事件、不检查
deleted_at，但你要自己确保$ids是合法且未被软删除的 —— 这个责任从框架转移到了你手上 - 若需保留软删除语义，得手动加条件：
['and', ['id' => $ids], ['deleted_at' => null]]
真正难的不是怎么跳过验证，而是判断“此刻是否真的可以跳过”——save(false) 像一把没保险的枪，扣扳机前得确认目标、弹药、后坐力都已在掌控之中。
