是的，MySQL 的 CHANGE COLUMN 不支持直接指定位置；Laravel 迁移中必须用 DB::statement() 执行原生 ALTER TABLE ... CHANGE COLUMN ... AFTER 语句，且字段类型需完整重写，否则会清空定义。
MySQL 中 CHANGE COLUMN 不支持直接指定位置？
是的，Laravel 的迁移默认不提供字段顺序控制，因为底层 Schema::table() 调用的是标准 SQL ALTER TABLE ... CHANGE COLUMN 或 MODIFY COLUMN，而原生 MySQL 在非首次添加字段时，AFTER 子句只在 ADD COLUMN 时生效，CHANGE/MODIFY 默认把字段放到最后——这是最容易困惑的点。
你执行 php artisan migrate 后发现字段跑到了表末尾，不是因为你写错了，而是 MySQL 就这么干的。
Laravel 迁移里怎么真正把字段插到某列之后？
必须绕过 Laravel 的抽象层，手写原生 SQL。Laravel 的 DB::statement() 是唯一可靠方式，且要确保数据库是 MySQL（PostgreSQL 不支持 AFTER）。
- 先用
php artisan make:migration move_field_after_another创建空迁移 - 在
up()方法里用DB::statement("ALTER TABLE users CHANGE COLUMN phone phone VARCHAR(20) AFTER name") -
down()里建议写个反向语句（比如移到最后或指定另一列后），否则回滚会失败 - 注意：字段类型必须完整重写，不能只写名字——
CHANGE COLUMN old_name new_name TYPE NULL，漏掉类型或约束会清空定义
为什么不能用 renameColumn() + after() 组合？
因为 renameColumn() 底层仍是 CHANGE COLUMN，不接受 after 参数；而 after() 只在 addColumn() 时被 Laravel 解析成 AFTER xxx SQL，对修改字段无效。
常见错误写法：Schema::table('users', function (Blueprint $table) { $table->string('phone')->after('name')->change(); }); —— 这段代码根本不会报错，但 after('name') 在 change() 上被完全忽略，字段仍移到末尾。
生产环境改字段顺序前必须确认三件事
这不是开发机随便试的操作：
- 确认 MySQL 版本 ≥ 5.7（
AFTER在早期版本行为不稳定） - 检查该字段是否有索引、外键或触发器——
CHANGE COLUMN会隐式删除再重建，可能中断依赖 - 如果表数据量大，
ALTER TABLE ... CHANGE COLUMN ... AFTER会锁表并复制全量数据，线上务必选低峰期，或提前加ALGORITHM=INPLACE（需满足条件）
字段顺序本身不影响查询性能或功能，纯属可读性需求。真要动，就得接受它本质是一次高风险 DDL 操作，不是 Laravel 配置开关。
