修改字段类型或属性必须用 change() 方法，否则迁移不生效；重命名字段须用 renameColumn()；生产环境需检查外键、数据兼容性及约束冲突，down() 必须严格逆向还原。
修改已有字段类型或属性必须用 change()
直接在迁移里改 Schema::table() 里的列定义（比如把 string() 改成 text()）不会生效——Laravel 默认跳过“未声明变更”的列。必须显式调用 change() 方法，否则 migrate 命令只是“假装执行”了。
常见错误现象：php artisan migrate 成功但字段没变；数据库里仍是旧类型；甚至在 MySQL 中遇到 SQLSTATE[HY000]: General error: 1832 Cannot change column 'xxx': used in a foreign key constraint。
- 确保已安装
doctrine/dbal：它提供列变更所需的底层 SQL 解析能力，Laravel 9+ 默认不自带，需手动composer require doctrine/dbal -
change()不支持所有数据库：MySQL 和 PostgreSQL 基本可用，SQLite 不支持列类型变更，会直接报错SQLSTATE[HY000]: General error: 1 Cannot modify column: use ALTER TABLE to modify column - 字段名、类型、长度、是否 nullable 都算可变更项，但修改主键、索引、外键约束需单独处理，
change()不管这些
Schema::table('users', function (Blueprint $table) {
$table->string('name')->change(); // ✅ 显式声明要变更
$table->text('bio')->nullable()->change(); // ✅ 同时改类型和属性
});
重命名字段必须用 renameColumn()，不能靠 change()
change() 只改列定义，不改名字；想改字段名，必须用独立的 renameColumn() 方法，且它和 change() 不能合并到同一个闭包里执行——否则第二个操作会被忽略或报错。
使用场景：比如把 user_name 改成 name，或统一字段命名风格。
-
renameColumn()在 MySQL 中实际执行的是CHANGE COLUMN，所以它也能顺带改类型（但不推荐这么干），例如：$table->renameColumn('old', 'new', 'TEXT')—— 这种写法 Laravel 文档已标记为 deprecated - 如果原字段有索引（比如
index('user_name')），重命名后索引名不会自动更新，得手动删旧索引、建新索引 - PostgreSQL 对列重命名更敏感，若该列被视图、函数依赖，会直接拒绝操作，需先处理依赖
Schema::table('users', function (Blueprint $table) {
$table->renameColumn('user_name', 'name'); // ✅ 正确
});
生产环境改字段前务必检查外键和数据兼容性
很多“改字段失败”不是语法问题，而是数据库层面的约束冲突。尤其是修改字段类型时，MySQL 会尝试转换存量数据，一旦遇到无法隐式转换的情况（比如把含非数字字符的 VARCHAR 改成 INTEGER），整个迁移就中断。
容易踩的坑：
- 把
nullable()字段改成notNullable()：必须先保证全表该列无 NULL 值，否则报错SQLSTATE[HY000]: General error: 1138 Invalid use of NULL value - 缩小字段长度（如
string(255)→string(50)）：若某条记录内容超长，MySQL 直接截断并警告，Laravel 不报错但数据已损毁 - 外键列类型必须完全一致（包括 signed/unsigned、字符集、排序规则），哪怕只是把
INT改成BIGINT，也得先删外键再重建
建议做法：先用 DB::select("SELECT ...") 查一遍目标列的数据分布，再决定是加中间迁移清数据，还是分两步走（新增字段 → 迁移数据 → 删旧字段）。
down() 方法里别只写 dropColumn()
回滚迁移时，如果 up() 做了字段变更或重命名，down() 必须还原成原始状态，而不仅仅是删掉字段。否则下次再 migrate:rollback 就会出错，或者导致表结构和代码预期不一致。
典型反例：
-
up()把title从string改成text，down()却只写$table->dropColumn('title')—— 这等于删了字段，而不是还原类型 - 重命名字段后，
down()忘记renameColumn('new', 'old')，导致回滚后字段名还是新的，但后续迁移又试图 rename 一次，报错重复列名 - 改了 nullable 状态，
down()没补回nullable()或默认值，导致模型保存时报错
最稳妥的做法：down() 严格对应 up() 的逆操作，类型、长度、约束一个都不能少。
change() 的行为有差异，特别是 Laravel 8 升 9 之后，doctrine/dbal 从 v2 升到 v3，部分旧写法会静默失效。上线前最好在 staging 环境用真实数据跑一遍迁移回滚链。 
