Laravel的Migrations：添加interger,string,timestamp类型字段default(null) 的陷阱

引言

我在开发 Laravel 应用程序时， 使用 Laravel 的 Schema Builder 添加整数类型字段时，即使设置了default(null)，数据库中仍然显示为NOT NULL。这个看似简单的陷阱可能会导致数据插入失败、应用程序行为异常等问题

问题现象

假设我们需要在一个现有的表中添加一个新的整数字段，并希望这个字段允许为 NULL：

Schema::table('order',function(Blueprint$table){$table->integer("settled_at")->default(null)->comment("业绩结算时间")->after("updated_at");});

我们期望在数据库中看到这样的定义：

settled_atINTDEFAULTNULLCOMMENT'业绩结算时间'

但实际上得到的是：

settled_atINTNOTNULLCOMMENT'业绩结算时间'

问题根源

这个问题的根本原因在于 Laravel 的 Schema Builder 对不同字段类型的处理方式不同。当我们为整数字段设置default(null)时，Laravel 并不会自动推断出该字段应该允许 NULL 值。在数据库层面，默认情况下整数字段是不允许为 NULL 的，除非显式声明。

在 MySQL 中，当一个字段没有显式设置为NULL时，即使设置了DEFAULT NULL，它也会被视为NOT NULL，这可能会导致意外的行为。

解决方案

要正确解决这个问题，需要显式地调用nullable()方法：

Schema::table('crm_refund_service_order',function(Blueprint$table){$table->integer("settled_at")->nullable()->default(null)->comment("业绩结算时间")->after("completed_at");});

这样，Laravel 就会生成正确的 SQL 语句，确保字段既能接受 NULL 值，又有适当的默认值。

其他数据类型的注意事项

这个问题不仅限于整数类型，其他数据类型也有类似的考虑：

字符串类型

// 正确 - VARCHAR 字段允许为 NULL$table->string("optional_field")->nullable();// 错误 - 如果没有 nullable()，字符串字段默认为 NOT NULL$table->string("optional_field")->default(null);// 仍会是 NOT NULL

时间戳类型

// 正确 - 时间戳字段允许为 NULL$table->timestamp("optional_timestamp")->nullable();// 错误 - 时间戳字段默认不允许 NULL（除非使用 timestamps()）$table->timestamp("optional_timestamp")->default(null);// 仍会是 NOT NULL

最佳实践

1. 始终明确声明：如果你的字段需要接受 NULL 值，务必使用nullable()方法。

2. 仔细测试：在运行迁移后，最好检查数据库中的实际表结构，确保符合预期。

3. 文档化：在迁移文件中添加注释，说明为什么某个字段需要为 NULL。

4. 使用数据库工具：使用像 Laravel IDE Helper 这样的工具可以帮助你在开发过程中发现潜在问题。