save(false)仅当已手动验证数据或明确无需校验（如后台补数据）时使用；否则会导致脏数据入库、验证失效、事务不自动回滚等严重问题。
save(false) 什么时候该用、什么时候不该用
直接说结论：save(false) 只应在你**已手动验证过数据**，或**明确知道当前字段无需校验**（比如后台脚本补数据、迁移字段值）时使用。它不是“绕过验证的快捷键”，而是“跳过模型规则校验”的开关——一旦滥用，validate() 静默失效，脏数据直插数据库。
常见误用场景包括：前端传参没 load() 就调 save(false)；字段类型不匹配（如 tinyint 规则写成 string）却只靠 save(false) 强行入库；或者在未设置 scenario 的情况下，指望 save(false) 解决场景校验失败问题——这些都不行。
save(false) 和 validate() 的真实关系
save() 默认调用 validate()，但 save(false) 完全跳过这一步，不触发任何规则、不检查 safe 属性、也不管你有没有定义 rules()。它只做两件事：拼 SQL（INSERT/UPDATE）、执行写库。
-
save()→ 先validate()→ 成功才写库 → 失败返回false，错误存于$model->getErrors() -
save(false)→ 直接写库 → 成功返回true，失败抛异常（如唯一键冲突、外键约束）或返回false（取决于 DB 驱动配置） - 即使你之前手动调过
$model->validate()，save(false)也不会复用那次结果——它彻底无视验证状态
实际操作中怎么安全用 save(false)
典型正确用法是「先校验逻辑，再跳过模型规则」。比如你从 JSON 接口接收数据，字段名不带 model 前缀，且部分字段需服务端强校验（非 rules() 能覆盖），这时：
$raw = Yii::$app->request->getRawBody();
$data = Json::decode($raw);
$model = new User();
// 手动校验关键字段
if (!isset($data['email']) || !filter_var($data['email'], FILTER_VALIDATE_EMAIL)) {
throw new BadRequestHttpException('Email format invalid');
}
if (strlen($data['name'] ?? '') setAttributes($data, false); // 第二个参数 false 表示不走 load() 的安全检查
$model->scenario = 'api'; // 即使不用 rules，也建议设场景便于日志/审计
// 跳过模型规则，但数据本身已由你确认合法
if (!$model->save(false)) {
throw new ServerErrorHttpException('Save failed: ' . json_encode($model->getErrors()));
}
注意：setAttributes($data, false) 和 save(false) 是配套动作；单独用 save(false) 而不控制属性来源，等于放弃 Yii 的安全边界。
容易被忽略的副作用和坑
save(false) 不仅跳过验证，还跳过所有 ActiveRecord 生命周期钩子中的验证环节——比如 beforeValidate()、afterValidate() 完全不执行。但 beforeSave() 和 afterSave() 依然会触发。
- 时间戳字段（
created_at/updated_at）仍会自动填充，前提是模型里启用了timestamps行为 - 主键自增 ID 在
save(false)后仍可通过$model->id获取（INSERT 场景），但$model->isNewRecord会在成功后自动变为false - 如果你在
update()场景下用save(false)，且数据库字段有ON UPDATE CURRENT_TIMESTAMP，那数据库层时间戳仍会更新——模型层不干预 - 最隐蔽的坑：事务中用
save(false)插入失败（如 NOT NULL 字段为空），不会自动 rollback，除非你显式捕获异常并处理
真正难的不是加 false，而是判断「此刻是否真的能跳过验证」——多数时候，问题出在 load() 没调对、scenario 没设准、或前端字段名和模型属性对不上，而不是规则本身不合理。
