up()定义结构变更，down()须严格逆向撤销；均用schema构建器保障兼容性；命名迁移通过artisan命令自动生成模板；迁移是版本化操作，已执行文件不可修改，生产环境需备份。
up() 用来定义数据库结构变更，down() 必须严格对应地撤销它——这是迁移可回滚、可协作的基础。
up() 方法：执行结构变更
所有新增或修改操作都写在 up() 里，通过 Laravel 的 Schema 构建器完成：
- 新建表：用
Schema::create('table_name', ...) - 修改已有表：用
Schema::table('users', ...)，再调用$table->addColumn(...)或$table->renameColumn(...) - 添加索引或约束：比如
$table->unique('email')、$table->foreign('user_id')->references('id')->on('users') - 避免直接写原生 SQL；优先使用构建器方法，保障跨数据库兼容性
down() 方法：精准逆向操作
down() 不是“删整个库”，而是把 up() 中每一步操作明确反过来：
- 如果
up()创建了表，down()就用Schema::dropIfExists('table_name') - 如果
up()给users表加了phone字段，down()就用Schema::table('users', function (Blueprint $table) { $table->dropColumn('phone'); }); - 如果
up()添加了唯一索引，down()要用$table->dropUnique('users_email_unique')（注意索引名需匹配） - 不能省略或写成空方法；否则
php artisan migrate:rollback会失败
命名与生成技巧
Artisan 命令能自动填充常见模板，减少手误：
-
php artisan make:migration create_posts_table --create=posts→up()默认含Schema::create()，down()含dropIfExists() -
php artisan make:migration add_status_to_posts_table --table=posts→up()和down()都预设Schema::table('posts', ...)，你只需补字段操作 - 文件名带时间戳，Laravel 按顺序执行，不依赖文件名语义
实际运行时的关键点
迁移不是一次性脚本，而是版本控制行为：
- 执行
php artisan migrate时，只运行migrations表中未记录的迁移 - 执行
php artisan migrate:rollback会调用上一次迁移的down()，并从记录中删除该条目 - 若修改了已执行过的迁移文件，不要直接改 —— 应新建迁移来修正，避免团队环境不一致
- 生产环境务必先备份再
migrate，尤其涉及数据迁移（如字段类型变更）时需额外处理存量数据
