laravel 迁移中可直接调用模型查询或工厂创建数据，但不建议实例化 seeder 类或混用种子逻辑，以免破坏迁移的幂等性与部署可靠性。
在 Laravel 开发中，开发者有时希望在数据库迁移（Migration）中复用 Seeder 中已封装的数据初始化逻辑（例如生成测试用户、预设分类等）。技术上可以实现，但设计上强烈不推荐——因为迁移的核心职责是安全、可逆、幂等地变更数据库结构与基础状态，而 Seeder 的定位是为开发/测试环境快速填充示例数据。二者关注点不同，混合使用易导致以下问题：
- ✅ 迁移不可回滚：若 Seeder 中包含 DB::table()->insert() 或模型 save() 操作，php artisan migrate:rollback 可能无法自动清理这些数据；
- ⚠️ 部署风险：生产环境执行迁移时意外触发种子逻辑（如创建默认管理员），可能违反权限策略或引发重复数据；
- ? 依赖耦合：Seeder 类通常不在服务容器中注册，手动 new DatabaseSeeder() 可能因构造函数依赖（如未注入 $container）而报错；且其 run() 方法非幂等，重复执行迁移将导致数据异常。
✅ 推荐做法：在迁移中「轻量级」操作模型，而非调用 Seeder
若确需在迁移中插入初始数据（如系统配置、角色权限等静态基准数据），应直接使用 Eloquent 模型或工厂，避免引入 Seeder 类：
// 在 up() 方法中（例如 create_users_table.php）
use App\Models\User;
public function up(MigrationBuilder $migration)
{
// ✅ 安全：使用模型查询（只读）
$admin = User::where('email', 'admin@example.com')->first();
// ✅ 安全：使用模型工厂创建（需确保 factory 已定义）
if (! $admin) {
User::factory()->create([
'name' => 'System Admin',
'email' => 'admin@example.com',
'is_active' => true,
]);
}
// ✅ 安全：批量插入（绕过模型事件，更高效）
DB::table('roles')->upsert([
['id' => 1, 'name' => 'admin', 'label' => 'Administrator'],
['id' => 2, 'name' => 'user', 'label' => 'Regular User'],
], ['id'], ['label']);
}? 提示：upsert()（Laravel 8.2+）是插入/更新的原子操作，适合维护小规模静态表，兼具幂等性与性能。
❌ 应避免的写法（即使语法通过）
// ❌ 错误：实例化 Seeder —— 违反单一职责，且 factory() 等方法在 Seeder 中依赖 app() 实例
$seeder = new DatabaseSeeder();
$seeder->run(); // 可能失败，且无法保证幂等
// ❌ 错误：在迁移中调用 Artisan 命令（如 `Artisan::call('db:seed', [...])`）
// 这会启动完整命令生命周期，破坏迁移上下文，生产环境极危险? 总结：坚守边界，按场景选方案
| 场景 | 推荐方案 | 理由 |
|---|---|---|
| 结构变更 + 少量基准数据（如角色、国家码） | 迁移中用 DB::table() 或模型 create() / upsert() | 控制粒度、可审计、可回滚（配合 down() 清理） |
| 开发/测试环境大量示例数据 | 单独运行 php artisan db:seed 或自定义 Seeder | 符合设计意图，支持分组、条件执行、调试友好 |
| 需要动态生成关联数据（如为每个 Category 创建 3 个 Product） | 在 Seeder 中实现，不要塞进迁移 | 逻辑复杂、非幂等、不应参与部署流程 |
牢记：迁移是数据库的“版本控制”，Seeder 是数据的“演示脚本”。保持二者分离，才能让应用在本地、CI、生产环境中稳定演进。
