MySQL的TINYINT等整型字段存不下PHP传值而报“Out of range”错误，是因为MySQL在执行update时严格校验数值是否在字段类型范围内，而Yii2的save()或updateAll()仅拼SQL、不校验取值边界；例如status为TINYINT(1)（-128~127），若PHP赋值200，MySQL直接拒绝并抛出原生错误。
MySQL 的 TINYINT、SMALLINT 等整型字段存不下 PHP 传来的值，直接报错 “Out of range value for column”，不是 Yii2 框架问题，而是数据库约束在拦截。
为什么 update() 会触发数字溢出错误
Yii2 的 ActiveRecord::save() 或 updateAll() 只负责拼 SQL，不校验字段取值是否落在 MySQL 类型范围内。比如数据库定义了 status TINYINT(1)（取值 -128 ~ 127），但代码里写了 $model->status = 200，执行时 MySQL 直接拒绝写入，并抛出原生错误：Out of range value for column 'status' at row 1。
- 该错误在
YII_DEBUG = true下会显示完整 SQL 和绑定参数，方便定位哪一列越界 - 若关闭调试，错误可能被静默吞掉或转成 500，需查
runtime/logs/app.log中的 PDO 异常堆栈 - 注意：PHP 层面的整数不会溢出（如
200在 PHP 是合法 int），问题完全在 MySQL 类型边界
快速验证字段类型与当前值是否匹配
别猜，直接查表结构和实际数据范围：
- 运行
DESCRIBE your_table;或SHOW COLUMNS FROM your_table LIKE 'status';，确认字段类型、是否UNSIGNED、是否有DEFAULT - 检查你正要更新的值：在控制器中加
var_dump($model->status, gettype($model->status)); die;，排除字符串误传（如'200'被隐式转成 int 后仍越界） - 特别注意时间戳类字段：用
int(11)存毫秒级时间戳（如1723904820000）必然溢出，应改用BIGINT
修复方案按优先级排序
根本原则：让数据适配字段，而不是绕过校验。
- 【推荐】修改数据库字段类型：用
ALTER TABLE your_table MODIFY COLUMN status SMALLINT或BIGINT，确保能容纳业务最大值；执行前先SELECT MAX(status) FROM your_table;看历史最大值 - 【临时兜底】在赋值前做 PHP 层截断：
$model->status = max(-128, min(127, $input));（适配TINYINTsigned）；但这是掩盖问题，上线前必须同步改库 - 【避免踩坑】不要用
CAST或CONVERT在 SQL 层硬转，MySQL 会静默截断并产生警告（Warning: 1265 Data truncated for column 'status'），且 Yii2 默认不抛出 warning 级异常 - 【警惕迁移脚本】如果用
yii migrate新增字段，务必显式指定长度和符号，例如：$this->addColumn('user', 'score', $this->integer(11)->unsigned());，否则默认INT可能不够用
批量更新时如何提前发现溢出风险
对 updateAll() 这类无模型实例的操作，无法靠 AR 的属性校验，必须手动兜底：
- 更新前用原生查询预检：
(new Query())->select(['MIN(value)', 'MAX(value)'])->from('your_table')->one();，确认目标值在安全区间内 - 拆分大批次为小批次（如每次 100 条），并在循环内加
try...catch(\yii\db\Exception $e)，捕获SQLSTATE[22003]（数值越界错误码）并记录违规主键 - 禁止在
createCommand()->update()中直接拼变量，必须用参数绑定：->update('table', ['col' => $val], ['id' => $id])，否则 SQL 注入+类型混乱双杀
最易被忽略的是 unsigned 字段和 PHP 负数的组合——比如字段是 TINYINT UNSIGNED（0~255），但代码传了 -1，MySQL 会转成 255（补码解释），结果值完全错乱。这种隐式转换不会报错，却导致业务逻辑崩溃，必须在开发阶段就用严格类型字段 + 显式校验守住边界。
