怎么修复Laravel在不同数据库环境下的布尔值转换报错

MySQL 8.0.16+ 中 TINYINT(1) 不再隐式映射为布尔值，Laravel 9+ 读取非 0/1 值会抛出 Invalid boolean value 错误；正确做法是用 boolean() 迁移并清洗脏数据。

MySQL 8.0+ 中 `TINYINT(1)` 不再自动映射为布尔值

laravel 9+ 默认把 tinyint(1) 当作布尔字段处理，但 mysql 8.0.16+ 关闭了这个隐式行为（sql_mode 默认含 strict_trans_tables），导致读取非 0/1 值时抛出 invalidargumentexception: invalid boolean value。

常见错误现象：SQLSTATE[HY000]: General error: 1366 Incorrect integer value 或模型取值时报 Invalid boolean value。

检查当前表结构：运行 SHOW COLUMNS FROM users LIKE 'active';，确认类型是 TINYINT(1) 且有默认值或历史数据含 2、-1 等
不推荐直接改 Laravel 的 casts 为 'integer' —— 会丢失自动转换语义，且 $model->active 返回 int 而非 bool
正确做法：在迁移中显式声明列类型为 boolean()（Laravel 9.2+ 支持），它会生成 TINYINT(1) UNSIGNED NOT NULL 并启用安全范围校验

示例迁移：

Schema::table('users', function (Blueprint $table) {
    $table->boolean('active')->change(); // Laravel 自动处理 UNSIGNED + DEFAULT 0
});

Laravel 模型中 `casts` 配置必须与底层类型对齐

如果数据库列仍是 TINYINT（非 BOOLEAN），而模型写了 'active' => 'boolean'，Laravel 会在 setAttribute 时强制转为 0 或 1，但 getAttribute 时仍尝试用 (bool) 强转原始值 —— 遇到 2 就崩。

Laravel Creem Agent

Creem 支付商店助理 — 查询订阅、客户、交易、产品，执行心跳检查，管理本地 Laravel支付商店。

下载

先确认实际数据内容：SELECT active, COUNT(*) FROM users GROUP BY active;，看是否有非 0/1 值
若存在脏数据，不能只靠 cast 修复；需先清洗：UPDATE users SET active = CASE WHEN active != 0 THEN 1 ELSE 0 END;
cast 写法优先用数组语法：protected $casts = ['active' => 'boolean'];，避免旧版字符串写法 'active' => 'bool'（部分版本不识别）
MySQL 中 TINYINT 是有符号的，但 Laravel 布尔 cast 默认按无符号处理；若列定义含 SIGNED，建议加 UNSIGNED 约束或改用 tinyInteger()->unsigned()

多数据库兼容场景下别依赖 `TINYINT(1)` 的布尔语义

PostgreSQL 没有 TINYINT，SQLite 的 BOOLEAN 实际存为整数，但 Laravel 对各驱动的布尔处理逻辑不一致 —— 比如 SQLite 下 cast 为 boolean 会走 PHP 的 filter_var($value, FILTER_VALIDATE_BOOLEAN)，而 MySQL 走的是自定义解析器。

跨库项目统一用 boolean() 迁移方法（Laravel 自动适配目标方言），不要手写 tinyInteger('active')->default(0)
测试环境用 SQLite 时，确保 DB_CONNECTION=sqlite 下跑过真实数据流，因为 SQLite 允许插入字符串 'true' 到布尔字段，MySQL 不行
如果必须保留 TINYINT 类型（比如遗留系统不允许改表），可在模型中覆盖 getActiveAttribute 方法，手动做容错转换：
```
public function getActiveAttribute($value)
{
    return in_array($value, [1, '1', true, 'true'], true);
}
```

生产环境改表前必须验证 `tinyint` 列的实际取值范围

很多团队直接执行 change() 迁移，结果发现某些列存了状态码（如 status 字段用 TINYINT 存 0=待审、1=通过、2=拒绝），强行 cast 为 boolean 后全变成 true，业务逻辑直接错乱。

查最大最小值：SELECT MIN(status), MAX(status) FROM orders;，若结果超出 [0,1]，说明这不是布尔字段，不该用 boolean cast
字段命名是关键线索：叫 is_active、has_paid 才适合布尔；叫 status、type、level 就该用 integer 或枚举 cast
改表后务必在日志里 grep Invalid boolean value，有些报错不会中断请求，只静默 fallback 到 false