Laravel迁移中使用hasColumn函数是否合理？为何不推荐条件判断？

在Laravel后端项目的代码评审中，我提出迁移操作里应该先检查字段是否存在，仅当字段不存在时再添加新字段，但团队里有人表示这种做法不推荐，我想搞清楚其中的原因。

原迁移代码 #

public function up(): void
{
    Schema::table('testing', function (Blueprint $table) {
        $table->boolean( 'boolean_test_value' )
              ->default( false )
              ->after('some_other_column' );
    });
}

我建议的修改方案 #

public function up(): void
{
    if (!Schema::hasColumn('testing', 'boolean_test_value')) {
       Schema::table('testing', function (Blueprint $table) {
           $table->boolean( 'boolean_test_value' )
                 ->default( false )
                 ->after('some_other_column' );
       });
   }
}

疑问 #

为什么这种先检查字段存在性再执行添加的做法，不是Laravel迁移的好实践？

【更新场景补充】 #

• 接到新工单，要求重新搭建整个数据库系统，且确保某条迁移最先执行（命名排序为第一个，所有新项目都会优先运行它）
• 如果不添加条件判断，在已有完整表结构的情况下，有人建议手动将该迁移记录加入migrations表以避免重复执行
• 这种场景下，为何依然不推荐在迁移中加入条件判断？

原因解析 #

Laravel迁移的核心设计目标是保证数据库状态的可追溯性和环境一致性，带条件判断的迁移会从根本上违背这个设计逻辑，具体原因如下：

1. 破坏迁移的确定性
   带条件的迁移执行结果完全依赖当前数据库的状态，不同环境（本地开发、测试、生产）可能出现完全不同的执行结果。比如部分环境字段已存在会跳过操作，部分环境则执行添加，这会导致各环境数据库结构出现隐性差异，后续排查问题时很难追溯根源。

2. 违背迁移的单一职责原则
   每个迁移文件应该对应明确且单一的数据库变更操作，比如“为testing表添加boolean_test_value字段”。加入条件判断后，这个迁移的职责变得模糊——它既可能是添加字段的操作，也可能是一个无意义的空操作，无法通过文件名和代码快速判断它实际完成了什么变更，增加了维护成本。

3. 手动维护migrations表是更合规的解决方案
   针对你提到的特殊场景：需要让某条早期迁移优先执行，但目标表结构已存在的情况，正确的做法是手动将该迁移的记录插入migrations表（注意保持批次号和其他迁移的逻辑一致性）。这种方式既保留了迁移记录的完整性，新环境执行迁移时会自动跳过已标记为完成的操作，同时所有环境的migrations记录保持一致，便于统一追溯数据库变更历史。

4. 增加后续调试和修改的复杂度
   当后续需要修改该字段（比如调整默认值、变更字段类型），带条件的迁移会让你陷入困惑：这条迁移到底在哪些环境执行过？如果直接修改原迁移代码，部分环境可能因为条件判断而不生效；如果新增迁移文件，又会和旧的条件迁移产生逻辑冲突，导致数据库变更逻辑混乱。

内容的提问来源于stack exchange，提问作者Jose Rafael Mendes Barbosa