Laravel模型创建？创建操作如何执行？

Laravel模型创建通过php artisan make:model生成骨架文件，结合save()、create()、firstOrCreate()等方法实现数据持久化，配合$fillable安全控制与模型配置如表名、主键、连接等，灵活应对不同场景的数据操作需求。

Laravel模型创建主要是通过Artisan命令

php artisan make:model

来生成对应的模型文件，这为我们与数据库表交互奠定了基础。而实际的创建操作，则涉及利用这些模型实例，通过

save()

方法、或者更便捷的

create()

、

firstOrCreate()

等静态方法，将数据持久化到数据库中。这两种操作，一个负责骨架，一个负责血肉，共同构成了Laravel中数据持久化的核心。

解决方案

创建Laravel模型通常从命令行开始，这就像是搭好了房子的大致框架。当你执行

php artisan make:model Post

时，Laravel会在

app/Models

目录下生成一个

Post.php

文件。这个文件就是你与

posts

表（默认情况下，Laravel会根据模型名推断表名，比如

Post

对应

posts

）进行交互的接口。

生成模型时，你还可以带上一些参数，比如

php artisan make:model Post -m

会同时生成对应的迁移文件，

-c

会生成控制器，

-r

生成资源控制器，或者直接来个

php artisan make:model Post --all

把关联的控制器、迁移、工厂、Seeder都一口气生成了。我个人在项目初期快速原型开发时，

--all

用得很多，省心。但如果数据库结构已经比较明确，或者需要更细致地控制，我可能就只生成模型和迁移，其他手动来。

模型文件本身，一开始会很简洁：

<?php  namespace AppModels;  use IlluminateDatabaseEloquentFactoriesHasFactory; use IlluminateDatabaseEloquentModel;  class Post extends Model {     use HasFactory; }

但要让它真正工作起来，尤其是在执行数据创建操作时，你需要关注几个关键属性，比如

$fillable

或

$guarded

，它们是处理批量赋值（mass assignment）安全性的核心。

接下来，数据创建操作才是真正把数据塞进数据库的步骤，这里有几种常见方式：

实例化模型，赋值，然后保存： 这是最基础也是最直观的方式。你先创建一个模型的新实例，然后逐个给它的属性赋值，最后调用
save()
方法。
```
use AppModelsPost;  $post = new Post; $post->title = '我的第一篇文章'; $post->content = '这是文章的具体内容，通过逐个赋值的方式添加。'; $post->user_id = 1; // 假设关联用户ID $post->save();
```
这种方式的好处在于，你在
save()
之前可以对数据进行各种复杂的处理、验证或者条件判断。它提供了最大的灵活性，尤其是在数据来源复杂或需要额外逻辑时。
使用

create()

静态方法： 这是最常用也最简洁的批量赋值方式。你直接向
create()
方法传入一个包含所有属性的数组，Laravel会帮你实例化并保存。
```
use AppModelsPost;  $post = Post::create([     'title' => '又一篇新文章，这次用create方法',     'content' => '批量赋值真是方便快捷。',     'user_id' => 2, ]);
```
但这里有个大前提：你的模型必须正确设置了
$fillable
或
$guarded
属性，否则会抛出
```
MassAssignmentException
```
异常，或者在某些版本中直接静默失败。这是为了防止安全漏洞，下面会详细聊聊。
firstOrCreate()

方法： 这个方法非常实用，它会尝试查找符合给定属性的记录。如果找到了，就返回该记录；如果没找到，就使用给定的属性（以及可选的额外属性）创建一条新记录。
```
use AppModelsCategory;  $category = Category::firstOrCreate(     ['name' => '编程'], // 用于查找的属性     ['slug' => 'programming'] // 如果创建，额外添加的属性 );
```
这对于需要确保某条记录（比如一个标签、一个分类）唯一存在，避免重复创建的场景特别有用。
firstOrNew()

方法： 与
firstOrCreate()
类似，它也会查找符合条件的记录。如果找到，返回该记录；如果没找到，则创建一个新的模型实例，但不会保存到数据库。你需要手动调用
save()
方法来持久化它。
```
use AppModelsTag;  $tag = Tag::firstOrNew(     ['name' => 'Laravel'],     ['description' => 'PHP框架'] );  if (!$tag->exists) {     // 可以在保存前做一些额外操作     $tag->created_by = auth()->id(); } $tag->save();
```
```
firstOrNew()
```
给了你在“找到或创建”这个过程中，更多的介入机会，可以在保存前对新实例进行进一步的修改。
updateOrCreate()

方法： 这个方法结合了更新和创建。它会根据第一个参数（查找属性）去查找记录，如果找到，就用第二个参数（更新属性）来更新它；如果没找到，就用这两个参数合并后创建一条新记录。
```
use AppModelsSetting;  $setting = Setting::updateOrCreate(     ['key' => 'app_name'], // 用于查找的属性     ['value' => '我的新应用名称', 'description' => '应用的名称设置'] // 用于更新或创建的属性 );
```
这对于需要“如果存在就更新，不存在就创建”的场景非常高效，比如用户配置、系统设置等。

如何安全地进行数据创建，避免批量赋值漏洞？

在Laravel中进行数据创建时，批量赋值（Mass Assignment）是一个非常重要的安全考量点。如果处理不当，可能导致严重的安全漏洞。简单来说，批量赋值漏洞就是攻击者通过提交额外的或恶意的字段，来修改数据库中他们本不应该修改的属性。

想象一下，你的用户注册表单只接收

name

和

email

。但如果用户在请求中偷偷加了一个

is_admin=true

的字段，而你的代码直接使用了

User::create($request->all())

，那么这个用户就可能直接成为管理员了。这显然是不能接受的。

Laravel通过模型中的

$fillable

和

$guarded

属性来防范这种风险：

Designer

Microsoft推出的图形设计应用程序

查看详情

$fillable

属性： 这是我个人最推荐也最常用的方式。你需要在模型中明确列出那些可以被批量赋值的字段。只有在这个数组中的字段，才能通过
create()
、
```
update()
```
等方法进行批量赋值。
```
// app/Models/Post.php class Post extends Model {     use HasFactory;      protected $fillable = [         'title',         'content',         'user_id',         // ... 其他允许批量赋值的字段     ]; }
```
这样做的好处是“白名单”机制，默认是拒绝的，你需要显式地允许。这大大降低了因为疏忽而引入安全漏洞的风险。
$guarded

属性： 与
$fillable
相反，
$guarded
属性用于列出那些不能被批量赋值的字段，其余未列出的字段则都可以被批量赋值。
```
// app/Models/User.php class User extends Model {     use HasFactory;      protected $guarded = [         'id',         'is_admin',         // ... 其他不允许批量赋值的字段     ]; }
```
虽然它也能起到作用，但我个人认为
$guarded
存在更高的风险。因为它是“黑名单”机制，默认是允许的，你必须记住去排除那些敏感字段。一旦你忘记排除某个新增的敏感字段，就可能引入漏洞。除非你的模型有非常多的字段，且绝大部分都允许批量赋值，否则我更倾向于
$fillable
。

如果你设置
```
protected $guarded = [];
```
，这意味着没有任何字段被“保护”，所有字段都可以被批量赋值。这在某些特定场景下（比如Seeder文件，或者一些内部API，你完全信任数据源）可能有用，但在处理用户输入时，这几乎总是一个危险的信号。

在实际开发中，始终坚持使用

$fillable

是一个好习惯。它迫使你思考哪些数据字段是真正可以由用户直接输入的，哪些是需要系统内部处理或保护的。如果你确实需要在某个特定场景下（比如在数据填充器

Seeder

或管理后台的某个高度信任的操作中）批量赋值一个

$guarded

字段，可以使用

forceFill()

方法，但请务必谨慎：

$user = User::forceCreate([     'name' => 'Admin User',     'email' => 'admin@example.com',     'password' => bcrypt('password'),     'is_admin' => true, // 即使 is_admin 在 $guarded 中，这里也会被赋值 ]);

forceCreate()

和

forceFill()

绕过了

$fillable

和

$guarded

的检查，所以只应在你完全控制数据来源且明确知道自己在做什么的情况下使用。

Laravel模型创建后，如何配置其与数据库表的关联？

模型创建后，Laravel的Eloquent ORM会自动尝试根据模型名来推断对应的数据库表、主键、时间戳等信息。但实际情况往往更复杂，你的数据库表名可能不遵循约定，或者主键不是默认的

id

。幸运的是，Eloquent提供了丰富的配置选项来处理这些情况。

自定义表名：

$table

属性默认情况下，Laravel会把模型名的小写复数形式作为表名。例如，
```
Post
```
模型对应
```
posts
```
表，
```
User
```
模型对应
```
users
```
表。如果你的表名不符合这个约定（比如，你可能在整合一个遗留系统，或者有自己的命名习惯），你可以在模型中通过
```
$table
```
属性明确指定：
```
class MyCustomPost extends Model {     protected $table = 'blog_posts'; // 告诉Eloquent，这个模型对应的是 'blog_posts' 表 }
```
这个配置非常常用，我经常遇到需要调整表名的情况。
自定义主键：

$primaryKey

属性 Eloquent默认假设每张表都有一个名为
```
id
```
的主键。如果你的主键列名不是
```
id
```
，你需要通过
```
$primaryKey
```
属性来指定：
```
class Product extends Model {     protected $primaryKey = 'product_id'; // 假设主键是 'product_id' }
```
非自增主键：

$incrementing

属性默认情况下，Eloquent会认为你的主键是自增的整数。如果你的主键不是自增的（例如，使用UUID作为主键），你需要将
```
$incrementing
```
属性设置为
```
false
```
：
```
class UuidModel extends Model {     protected $primaryKey = 'uuid';     public $incrementing = false; // 告知Eloquent主键不是自增的     protected $keyType = 'string'; // 如果主键是UUID，通常是字符串类型 }
```
注意，当主键不是自增时，通常它的类型也不是整数，所以还需要设置
```
$keyType
```
。

自定义主键类型：

$keyType

属性如果你的主键不是整数类型（比如UUID，或者字符串编码），你需要设置

$keyType

属性：

class UserToken extends Model {     protected $primaryKey = 'token_string';     public $incrementing = false;     protected $keyType = 'string'; // 主键是字符串类型 }

禁用时间戳：

$timestamps

属性 Eloquent默认会维护
```
created_at
```
和
```
updated_at
```
这两个时间戳字段。如果你的表没有这两个字段，或者你不想让Eloquent自动管理它们，可以将
```
$timestamps
```
属性设置为
```
false
```
：
```
class SimpleLookup extends Model {     public $timestamps = false; // 禁用时间戳 }
```
这在一些简单的查找表或枢纽表（pivot table）中很常见。

自定义时间戳字段名：

created_at

和

updated_at

常量如果你的表有时间戳字段，但它们不叫

created_at

和

updated_at

，你可以通过在模型中定义常量来指定：

class CustomTimestampModel extends Model {     const CREATED_AT = 'creation_date';     const UPDATED_AT = 'last_update_time'; }

指定数据库连接：

$connection

属性如果你的应用连接了多个数据库，并且某个模型需要使用非默认的数据库连接，可以通过
```
$connection
```
属性来指定：
```
class ExternalData extends Model {     protected $connection = 'mysql_secondary'; // 使用 'mysql_secondary' 数据库连接 }
```
这在处理多租户应用或与外部数据源集成时非常有用。

这些配置提供了极大的灵活性，让Eloquent能够适应各种复杂的数据库结构和命名约定。在我自己的项目中，尤其是在处理旧系统或第三方数据时，这些配置几乎是不可或缺的。它们让Eloquent在保持强大功能的同时，也能保持高度的适应性。

在实际开发中，何时选择不同的创建方法（

save()

create()

firstOrCreate()

）？

在实际开发中，选择哪种数据创建方法，并非哪个“更好”的问题，而是哪个“更适合当前场景”的问题

以上就是Laravel模型创建？创建操作如何执行？的详细内容，更多请关注mysql php word laravel go php框架编码 app ai 注册表用户注册 php laravel 常量字符串接口整数类型 protected table 数据库

解决方案

如何安全地进行数据创建，避免批量赋值漏洞？

Laravel模型创建后，如何配置其与数据库表的关联？

在实际开发中，何时选择不同的创建方法（

save()

vs

create()

vs

firstOrCreate()

）？

大家都在看：

解决方案

如何安全地进行数据创建，避免批量赋值漏洞？

Laravel模型创建后，如何配置其与数据库表的关联？

在实际开发中，何时选择不同的创建方法（ save() vs create() vs firstOrCreate() ）？

大家都在看：

推荐文章

在实际开发中，何时选择不同的创建方法（

save()

vs

create()

vs

firstOrCreate()

）？