unsignedInteger() 仅适用于新建字段，无法直接为已有字段添加无符号限制；需用 DB::statement() 执行原生 ALTER TABLE 语句修改。
unsignedInteger() 不能直接用在已有字段上
想给一个已经存在的 id 或 amount 字段加无符号限制？不行。unsignedInteger() 只在新建字段时生效，Laravel 的迁移系统不会对已有列“补加” UNSIGNED 属性。MySQL 层面需要 MODIFY COLUMN 或 CHANGE COLUMN，但 Laravel 的 Schema 构建器默认不生成这类语句。
- 新建表时直接写
$table->unsignedInteger('score')，会生成带UNSIGNED的列定义 - 已存在字段要改，必须用
DB::statement()手动执行原生 SQL，比如：DB::statement('ALTER TABLE users MODIFY score INT UNSIGNED') - 注意：MySQL 8.0+ 对
MODIFY有严格要求（如不能跳过数据类型），建议先查当前列定义：SHOW COLUMNS FROM users LIKE 'score'
unsignedInteger() 和 integer()->unsigned() 效果一样吗？
效果相同，但底层行为略有差异。两者最终都生成 INT UNSIGNED，但调用链不同：
-
$table->unsignedInteger('age')是快捷方法，直接走 Schema Builder 的预设分支 -
$table->integer('age')->unsigned()是链式调用，在integer()返回的 Blueprint 实例上调用unsigned()方法 - 实际生成的 SQL 完全一致；但后者更灵活——比如你想对
bigInteger()或tinyInteger()也加 unsigned，就只能用->unsigned()链式写法
unsignedInteger() 在 SQLite 和 PostgreSQL 下会怎样？
直接失效，且不报错。SQLite 根本没有 UNSIGNED 概念，所有整数都是有符号的；PostgreSQL 也没有原生 UNSIGNED INTEGER 类型。Laravel 的 Schema 编译器会悄悄忽略 unsigned() 调用，生成普通 INTEGER。
- 开发环境用 SQLite、生产用 MySQL？字段范围可能不一致：比如
unsignedInteger在 MySQL 最大值是 4294967295，SQLite 却只认 -2147483648 ~ 2147483647 - 如果业务逻辑依赖无符号特性（比如绝不允许负数），别只靠数据库约束，应用层也要做校验，比如用
Rule::gte(0) - 跨数据库部署时，建议统一用
bigInteger()+ 应用层控制，比强依赖unsigned更稳妥
unsignedInteger() 和 autoIncrement 主键混用要注意什么？
主键用 $table->id()（等价于 bigIncrements('id')）时，默认就是无符号；但如果你手动写 $table->unsignedInteger('id')->primary()，会出问题：
- MySQL 报错
Incorrect table definition; there can be only one auto column and it must be defined as a key—— 因为unsignedInteger('id')->primary()没带autoIncrement()，不是自增列，但你又把它当主键用，后续想加->autoIncrement()会被拒绝 - 正确做法：主键一律用
$table->id()或$table->bigIncrements('id')；非主键计数字段（如view_count）才用unsignedInteger() - 迁移回滚时，
unsignedInteger()字段能正常删，但如果是你手动加了autoIncrement()到非标准字段，回滚可能失败
事情说清了就结束。unsigned 不是开关，它是和数据库引擎、字段用途、迁移生命周期绑在一起的细节。改老字段、换数据库、配主键，每一步都容易漏掉隐含前提。
