Laravel怎么设置默认值_Laravel模型属性默认设置【介绍】

在Lara vel开发中，给模型属性设置默认值看似简单，但背后其实有三套不同的机制在运作。这三者生效的时机截然不同，一旦用混了，代码在本地测试时可能一切正常，但到了生产环境，数据就可能出现各种意想不到的空值或错乱。

模型构造时设置默认值用 $attributes

最直观的方法，就是在模型类里定义 $attributes 数组。当你使用 new Model 或 Model::make() 创建一个新实例时，如果没给某个字段传值，Lara vel就会用这里定义的默认值来填充。

不过，这里有个常见的误区：很多人以为在模型里设置了 $attributes，就能覆盖数据库表结构里定义的 DEFAULT 约束。其实不然，这两者是独立运作的。数据库的默认值是在执行SQL INSERT 语句时生效的，而 $attributes 仅仅作用于PHP层面新建的那个模型对象。

使用 $attributes 时，有几个细节需要留意：

• 数组里的键名必须和数据库字段名完全匹配，包括大小写和下划线。
• 如果字段是JSON类型，或者需要序列化，别直接把数组或对象塞进去。Lara vel不会自动帮你序列化，需要配合 $casts 属性来使用。
• 对于时间字段，比如 created_at，最好不要硬编码一个字符串。更推荐的做法是使用 Carbon::now()，或者干脆留空，让Lara vel的自动时间戳功能来处理。

class User extends Model
{
    protected $attributes = [
        'status' => 'active',
        'score' => 0,
        'meta' => '[]', // 注意：JSON 字段要存字符串格式
    ];
}

数据库迁移里设默认值必须用 useCurrent() 或 useCurrentOnUpdate()

如果你希望默认值是在数据插入数据库的那一刻，由数据库自己来填充（比如自动生成的时间戳或UUID），那就不能只依赖PHP了，必须在数据库迁移文件里明确声明。

这里有个坑：Lara vel的Schema构建器对不同数据库的行为并不完全一致，尤其是MySQL和PostgreSQL，它们对 DEFAULT 子句的解释可能大相径庭。

举个例子，直接写 ->default('uuid()') 会被数据库当成一个普通的字符串字面量，而不是函数调用。虽然可以用 ->default(DB::raw('uuid()')) 来绕过，但SQLite又不支持这种写法，容易导致迁移失败。

所以，正确的姿势是：

• 设置时间戳默认值，统一使用 ->useCurrent()（适用于MySQL 5.6.5+和PostgreSQL）或 ->useCurrentOnUpdate()。
• 设置UUID字段，在PostgreSQL下推荐用 ->uuid()->default(DB::raw('gen_random_uuid()'))，在MySQL下则用 ->string()->default(DB::raw('UUID()'))，并且要确认数据库驱动确实支持这些函数。
• 对于普通的字符串或数字默认值，直接写 ->default('draft') 即可，这种方式通常能安全地跨数据库工作。

creating 模型事件比 $attributes 更灵活但更重

当默认值需要依赖运行时的上下文来决定时，比如当前登录用户的ID、请求的来源，或者一个随机生成的令牌，静态的 $attributes 数组就无能为力了。这时，模型的 creating 事件就该登场了。它允许你在模型被保存到数据库之前，动态地为其属性赋值。

需要注意的是，creating 事件只在调用 sa ve() 或 create() 方法时才会触发。如果你只是用 make() 方法创建了一个模型实例，它是不会执行的。更隐蔽的一个坑是，当使用 insert() 进行批量插入时，模型事件根本不会被触发，这一点很多人都会忽略。

使用事件监听器时，有几点最佳实践：

• 避免在 creating 事件里执行耗时的操作，比如发起HTTP请求或复杂的数据库查询，这会影响整体性能。
• 如果你要设置的字段受到模型 $fillable 或 $guarded 属性的限制，请确保它也在允许填充的白名单里，否则赋值会被过滤掉。
• 当有多个事件监听器同时监听 creating 事件时，它们的执行顺序是不可控的，不要对执行先后顺序做任何假设。

protected static function boot()
{
    parent::boot();

    static::creating(function ($model) {
        if (empty($model->uuid)) {
            $model->uuid = Str::uuid()->toString();
        }
        if (! $model->sort_order) {
            $model->sort_order = self::max('sort_order') + 1;
        }
    });
}

填充器（Accessors & Mutators）不是设默认值的工具

有时会看到一种做法，试图通过定义访问器（getFooAttribute）或修改器（setFooAttribute）来“模拟”默认值。这其实是一种误解。

访问器只影响从模型读取属性时的值转换，修改器只影响给模型属性赋值时的预处理。它们都无法解决“当字段在插入数据中完全不存在时，应该给它一个什么值”这个根本问题。

比如说，你写了一个 setPriceAttribute 方法，试图把空值转换成 0。这看起来像是在设置默认值，但实际上它只拦截了显式给 price 属性赋值的动作。如果创建记录时，price 字段压根没出现在传入的数据数组里，这个方法根本不会被调用，默认值自然也就无从谈起。

所以，记住它们的定位：

• 访问器和修改器更适合做数据格式的转换，比如统一存储小写、进行单位换算，而不是作为设置默认值的兜底逻辑。
• 如果非要用修改器来实现兜底，必须配合 isset($this->attributes['field']) 来判断属性是否已被设置，而且这只在显式赋值的场景下有效。
• 更稳妥、更清晰的方案，还是回到前面提到的 $attributes 数组或 creating 事件。

说到底，为Lara vel模型设置默认值，关键就在于厘清你希望这个值在哪个环节生效：是在PHP对象诞生的那一刻，是在SQL语句执行插入的瞬间，还是在模型即将被保存的前一刻。选对了时机，数据才能如你所愿地乖乖就位。