迁移文件中不应写批量更新数据逻辑，因其本质是数据库结构版本控制而非数据同步工具，否则会导致重复执行、环境不一致和回滚失效三大问题。
迁移文件里不能写批量更新数据的逻辑，Laravel 的 migrate 命令只负责结构变更（建表、加字段、改类型），不执行业务数据更新；真要批量改数据，得用 DB::table() 或 upsert() 等运行时方法，而不是塞进迁移里。
为什么迁移里不该放 update() 或 upsert()
迁移本质是「数据库结构版本控制」，不是数据同步工具。把 DB::table('users')->where('status', 0)->update(['status' => 1]) 写进 up() 方法，看似能跑通，但会埋下三个硬伤：
- 重复执行风险：迁移一旦标记为已执行，下次
php artisan migrate就跳过它；但如果数据又变脏了，你没法靠重跑迁移修复 - 环境不一致：开发机上跑过的数据更新，不会自动同步到测试/生产库——迁移表
migrations只记文件名，不记数据状态 - 回滚失效：
down()很难精准逆向数据变更（比如你把 100 条 status=0 改成 1，down()是全改回去？还是只改当时被影响的那批？没上下文）
真正该在哪批量更新数据
数据更新必须脱离迁移生命周期，放在明确可控的执行点：
-
Artisan 命令：新建
php artisan make:command FixUserStatus，在handle()里用DB::table('users')->where(...)->update(...)或User::upsert(...)，按需手动触发 -
Seeder：适合初始化或修复性数据填充，运行
php artisan db:seed --class=UserStatusFixerSeeder；注意 seeder 不受迁移版本约束，可反复跑 -
HTTP 端点（慎用）：仅限内部管理后台，加权限和确认机制，例如
POST /admin/fix-user-status调用对应 service 方法
如果非要在迁移后顺手更新数据，怎么收口
极少数场景（如上线新字段后立刻补默认值），可在迁移文件末尾加一层防护，但必须满足两个条件：只读判断 + 幂等操作：
- 先查再定：用
DB::table('users')->whereNull('new_column')->count()判断是否需要处理，避免每次 migrate 都扫全表 - 用原生 SQL 批量更新：比如
DB::statement("UPDATE users SET new_column = 'default' WHERE new_column IS NULL LIMIT 1000")，配合循环分页，防锁表 - 绝对不要依赖模型事件或访问器：迁移阶段 Eloquent 初始化不完整，
User::where(...)->update(...)可能跳过软删除作用域，且不触发updating
最易被忽略的一点：哪怕只是补个默认值，也要在命令行加 --force 提示，或者把这类“带数据操作”的迁移单独归类（如命名含 _data_fix），避免被 CI/CD 流水线无脑执行。
