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 就崩。
- 先确认实际数据内容：
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]，说明这不是布尔字段，不该用booleancast - 字段命名是关键线索：叫
is_active、has_paid才适合布尔；叫status、type、level就该用integer或枚举 cast - 改表后务必在日志里 grep
Invalid boolean value，有些报错不会中断请求，只静默 fallback 到false
最麻烦的不是语法怎么写，而是分不清“这列到底是不是布尔”——名字像、类型像、历史数据却不像。得先翻业务文档，再查数据分布，最后才动手改代码或表结构。
